Category archive

Project Management - page 3

Five Simple Guidelines to Agile Metric Bliss

in Agile/Agile Engineering/Project Management by

Over the past couple years, I’ve had the opportunity to work with many great teams in many industries. I often work with teams and their managers to generate reports. In doing so, I quickly realize that although teams may be working to adapt and leverage one of the frameworks that fall under the Agile moniker, they are not yet adopting or clearly understanding the Agile Principles and Values. This comes through clearly when we look at the kinds of reports people are using.

kittenI’ve seen dashboards that compare multiple team’s velocity. Or, the classic utilization report that shows time worked by team member. Or, the quality reporting that focuses on who versus what. And then there is the singular snapshot that represents percentage of backlog done – doesn’t sound that bad until you have a manager have kittens because the percentage is not what as expected.

Now, I have to admit — I’ve made all these reports before and used them myself. Sometimes the purpose of the report had an intended outcome, but my best intentions sometimes resulted in gamesmanship of the numbers or fear by the team and in one case, a team member pulled me aside worried that he may be culled.

Let’s face it, all metrics and reports can be used for bad. But what do you need to do to create good metrics? There are some great resources all over the internet that help answer this question, but let me give you my top five things you can do to make your metrics effective while fostering an agile environment:

  1. Make them Transparent. This is obvious, but often I see people create reports and don’t share them. I get that there are some reports for “their eyes only”; however, in most cases, if not all, unless it has salary information — make the reports visible to everyone – the Team, Stakeholders, Managers, and even Customers.
  2. Make them Visual. Use charts, shapes, colors, and or pictures over a table of figures. We do this for three reasons – easy to read, reduces the likelihood that people focus solely on outlier values, and in many cases — creates conversations. By the way, use colors wisely — just like words, colors mean stuff.
  3. Follow the Trends. Goes hand-in-hand with visualize — a good metric should be informative provided indicators that make it easy to see if the needle is pointing up or pointing down. Trends generally allow you to decide if what we are doing is good or bad, and reduce snap decisions.
  4. Make them Relevant and Timely. There are the out-of-the-box metrics — burn downs, cumulative flow, burn ups, cycle time, and or velocity – that should be maintained on a daily, weekly, or iteration basis — updating them in arrears does no good. This is the same for all agile metrics. Since the goal of any metric should be to continuously improve in some way, reports/metrics that are created or updated weeks or months after the fact does us no good. And, couldn’t we better utilize the time and brain power on something current.
  5. Have a Purpose. Every report or metric needs to be leveraged for importance. If you cannot answer two questions about a report or metric, maybe you should stop spending time and money to create the report. First, why are we creating this report? And, second, what will we do if the report is indicating a need to adjust or change?

Now, these are my five simple (and in some cases, general) guidelines – what are your’s? Do you have any suggestions?

Always keep in mind …

Working software is the primary measure of progress.

Continuous attention to technical excellence and good design enhances agility.

At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.Agile Manifesto

Put It On The Team

in Agile/Agile Engineering/Project Management/Teams by

Do you want to have more effective daily stand-ups? Do you want to have the planning meetings flow better and increase the value of these meetings? Do you want to see continuous improvement flow from your retrospectives?

If your answer is yes, then put it on the Team.

I’ve written about trust, relying on strengths, and improving self-organization many times — and the message of these can all be summed up as putting it on the Team. Make the team responsible for solving problems, make the team responsible for defining how to deliver, and making the team accountable for delivery. Most of the times when we talk about the concept of the Team self-organizing, is it more focused on the “how” part of delivery, and not the process. However, remember that the meetings (or ceremonies as some call them) are primarily for the team. Specifically, the Iteration Planning, Daily Standup (or Daily Scrum), and the Retrospective meetings — these are for the team, not the stakeholders or managers. Do the stakeholders and managers gain value from these meetings — Yes, but the real value is the fact that the Team takes ownership of what they are going to deliver, they take ownership on holding each other accountable to deliver and working through problems themselves, and they take the on responsibility the responsibility of improvement.

A lot of times we (as in Managers, Scrum Masters, Team Leads, Type-A Team Members) want to install processes and templates around these meetings. This usually happens after a few weeks or several months of trying an agile framework and either not following the guidelines of the framework or the team not taking the initiative to make improvements. We’re not getting any value and the team is resisting and or blaming the whole concept — we want to fall back to more structure and being told what to do.

A great example of this is when a team’s stand ups start becoming mundane, over-run their time boxes, and team members don’t show up. So what happens is we come up with a template for the team to keep up with for daily stand ups as well as establish a set of metrics we answer to during the stand-up. And of course, this just becomes one more thing for a team member to keep track of as well as an unintentional mechanism of command-and-control.

As an ex-Director/Manager, I often wanted to step in and help — and I usually would come up with a template and or some hard-prescribed structure and tell the team to follow it. I wanted to help and that’s what managers genuinely want to do, but I was quickly put in my place when one of my team members said, “let us figure it out, it’s our problem.” I gave guidance and advice, but otherwise I got out of the way. I let the Team come up with how they were going to make their meetings more effective. And at the end of the day, they simply looked at the frameworks themselves and decided to more closely follow the existing framework guidelines — e.g. keep stand-ups at 15 minutes and stick to the script, then allow the time remaining to become open space troubleshooting time.

TeamworkAt the end of the day, remember that more process does not equal more better. Rely on the Team to solve problems, over instituting process and templates to solve problems. I think I’ve heard this before somewhere …

Unintended Consequences of Good Intentions

in Project Management by

lightbulbHave you ever sat back and wandered about unintended consequences of good intentions. There are a lot of real life examples, but two I’ve reflected on lately are:

  • In the late 90’s we saw a push to increase home ownership, and we saw the creation of easy-to-access home loans that led the way to an overly loose banking environment where folks we’re able to bite off debt that they weren’t able to swallow. The banks then started to traded these risky debts, and well, we all know how this ended.
  • Over the last 15 years there’s a heightened awareness of taken care of what we have in the way of natural resources and improving energy conservation. This has resulted in the advent of some great new products and in some areas regulations that require the usage and or sale of such products. So now, the only kind of shower head you can get is a low flow an lightbulbs are generally some type of fluorescent. Putting these in new homes works well, but putting them in my home has resulted in my wife and I having to run the shower for 15 minutes before we can step in to let the water warm up. And, my wife has to turn on lights at least a minute or two before you enter the room so that the bulbs reach full glow. I don’t know if either of these are actually helping us conserve energy or sace our natural resources.

On our software teams we’ll often make decisions that start out well, then we get down the path for a while and find that the decisions we made six months ago are actually resulting in bad behaviors, poor morale, innefficiencies, and unfortunately crappy products. Without calling out specific examples from my past, let me just say that there have been plenty of times when the teams I’ve worked on have made a well intentioned decision that we later looked back on and realized that the decision resulted in some unintended consequences. The good thing about these situations is that we usually learned from these situations.

Some of the things I’ve learned are:

  • Always have an end goal in mind when making a decision. Even a quick decision should have some desired result whether positive or negative (hopefully positive).
  • With that goal in mind, revisit it on a regular basis near the time the decision is made. What I mean by this is that a decision that is made and then revisited six months later has either been rooted in or already rotted and nothing but a bad taste in the mouth.
  • When revisiting, there should be three directions in mind that you can take – stay the course, adjust, and abandon for another brilliant decision.
  • When you realize the unintended consequences, don’t look to lay blame or worse yet become overly reactionary. Instead, remain calm, asses the position of the decision against the goal and make a new decision.
  • Learn from the past decisions, and keep moving forward. Don’t dwell too long on a loss or a win – there’s always another opportunity around the corner. There’s an emotional aspect to winning and losing, make sure that you don’t let these emotions get in the way of deciding the right next steps.

So, what decisions have you made that were based on good intentions that resulted in unintended consequences?

How can team members help become an effective, self-organizing team?

in Project Management/Teams by

In my last post, I took a stab at answering the question “How do we change from individuals in workgroups to effect, self-organizing teams?” Through my discovery and reflection on that topic, I turned my focus towards the environment of the team. Now we know that environment is a big part, but the individuals do have an impact and over the years I’ve found some ideas that really impact how we as individuals can ensure we help the team become an effective, self-organized team.

  • Respect. It goes without saying that team members need to exhibit respect towards one-another. The idea of respect is often woven into an organization’s core values; however, it takes self-discipline to be sure we are treating each other with respect. It is sometimes said that at the end of an argument and or discussion, it is OK to agree-to-disagree as long as we all respect each other afterwards. Well, I would say — show respect during the time of the argument and or discussion. If you do, you’ll often find a faster resolution and you’ll avoid that “uncomfortable”, “bad taste in mouth” after effect.
  • Embrace Diversity. It is often not fully appreciated to have a team made up of members from different backgrounds, but in my experience — this is when the best results appear. Diversity can be demographic related or experience related, in all cases it simply comes back to learning. By listening to each other and sharing ideas, we learn from each other and inevitably, produce better and enjoy producing. One other by-product of leveraging cross-functional product teams, is of course diversity. The diversity of skill sets swarming on delivering a story helps do so faster with higher value and higher quality.
  • Trust. Trust is earned. It is primarily earned by doing what we say were going to do when we said we are going to do it. This is a huge challenge and we need to understand as individuals working in a team that a commitment you make reflects upon the team. Therefore, when we commit to completing work during an iteration and deliver on this commitment, we are establishing trust with the business. During our daily stand ups, when we are actionable about what we finished and what we plan to finish, we establish trust in the team.
  • Focus on Strengths. Much like embracing diversity, we must focus on the strengths of the team members and put each other in a position to succeed. We all-too-often look to improve our weaknesses either by taking on tasks that will force us to learn. Well there’s a difference between improving our skills and experiences, versus improving our weaknesses. A couple years ago, I wrote about how my team used Strengths Finder to better understand where each team member play’s best. From this point, we would define and divvy up work to get the iteration delivered based on our strengths. This became a very natural approach and team members had each other’s back when someone was playing outside their wheelhouse.
  • DO. I have often used the phrase – have a “will do attitude.” One of the best way of having teams form and self-organize is simply by doing. Do have the hard discussions. Do spend time with each other beyond work — build teams. Do swarm. Do pair. Do work hard. Do have each other’s back. Do adjust when necessary. Do make a difference. Do encourage each other. Do make decisions. Do what you said your going to do. Do appreciate each other’s opinions. Do lead. Do follow. Do take time to reflect. Do step away when necessary.

Team workThese ideas and concepts are definitely not mind blowing, nor are they new. But, as I mentioned, these are the basics that I’ve seen work. What are some of the individual behaviors and or practices have you’ve seen or done that helped ensure your team self-organizes?

SUCCESS = RESULTS – EXPECTATIONS

in Project Management by

When I talk with folks learning about Agile, I often play the game Presto Manifesto where the room talks about what it means to have a successful project and then break up into groups and based on their experiences come up with a list of critical elements that they’ve noticed on successful projects. This exercise is meant to bring people to the concepts of what makes up the Agile Manifesto.
success
The interesting thing is that in many cases we discover that we’re programmed to believe that failures of projects relate to not knowing everything up front. I almost always hear, “complete, thorough, and approved requirements” as an element of successful projects. This programming aligns well to the formula of success I learned during a short stint at an ERP consultancy firm:

SUCCESS = RESULTS – EXPECTATIONS

This formula leads us to make sure we set clear expectations so that we can meet and hopefully exceed them; thus, leading to success. However, as we know and learn in Agile (and really any process) – thinking the users/customers know everything about a project (a.k.a. need) six-to-nine months before they get their hands on it is simply a fallacy. Sure we can make the customers agree to the expectations ahead of time, but doesn’t that negate the ability to ensure that value and ROI is actually achieved on the project. What generally happens is that the customer/user defines the requirements and agrees to them, then sometime about a month before the project is delivered — they get their hands on some working capabilities and the say, “this doesn’t work like I expected, can you add a screen that does this and we’ll need a report that gets generated daily; if we don’t get these, we really can’t use this.” The response of the team is first, “but you signed the requirements document” or “those are great ideas, we’ll need to do that in the next phase” or “that will need to go through the change control process, we’ll need to escalate this.”

Ultimately, the team is not happy because they don’t get to experience SUCCESS because the RESULTS fall short of EXPECTATIONS. On-top-of-this, the customer is not happy either.

By using an Agile approach, we can improve on our SUCCESS rate through applying these very basic ideas:

  • The customer (a.k.a. the Product Owner) stays engaged with the team delivering throughout the project life-cycle. In fact, they are part of the team. At no point in the process should they disengage; thus, decisions and expectations are set near the time the need is built and subsequently delivered – requirements evolve. And since the customer stays engaged, changes should not be surprises to either the delivery team or the customer.
  • Needs are delivered in small valuable bites. This means that the delivery team and customer work together to understand what is smallest piece of value that should be delivered first and they deliver just that. This approach helps both the customer and delivery team by narrowing focus which results in faster delivery and a focus on getting the high-value need right (with quality). By the way, if the delivery team falls short of expectations for some reason it should not be a surprise to anyone and since we handle just a small bite – we fail small.
  • At regular intervals the delivery team (including the Product Owner) shows off the demonstrable product increment. Preferably what is demonstrated is a complete capability; however, this is not always possible. At a minimum enough is demonstrated so that feedback can be provided and the team can show that they are doing what they said they would. This demonstration provides a checkpoint for measuring success as well as it provides a way that expectations can be continuously molded and refined.
  • Conversations are constant within the delivery team, with the customer, and the stakeholders. Instead of having formal meetings that are dubbed “Status Meetings” — we have ongoing, regular discussions about the EXPECTATIONS. When an engineer has a question, they grab the key team members and product owner and discuss real-time. This results in clear understanding and a lack of hand-off breakdowns (where information is translated as it passes from one person to another).

There are many more things we do with agile delivery methods that ensure our projects are successful (e.g. continuous planning, short release cycles, engineering best-practices, and a ephemeral drive to get better). But if you start with the above ideas, I can assure you that the team and the customers will start getting that feeling of SUCCESS.

What are your thoughts?  How does your team measure success? Another great question, do you define SUCCESS before you start your projects?

Go to Top