Category archive

Agile - page 6

The Daily Standup from Hell

in Agile/Humor by

I’m always looking for some good videos, and I’ve found several funny ones that various folks have created around the subject of daily standups or daily scrum. I’ll post these over the next several days.


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 …

Product Ownership – A Team Sport?

in Agile/Product Management by

How many of you have heard a Product Owner being described as a single-wring-able-neck, or read that the Product Owner is solely responsible for the “Return On Investment” of a product or project? Are you aware that the Product Owner is responsible to work with stakeholders to define the product or project, and they are also required to be available to the team to answer questions, give feedback, and accept the deliverables produced by the team? If you are doing Scrum, you’ve likely heard all of this.

As defined by, the role of Product Owner is responsible for the business value of the project. To take this a step further, Roman Pichlar inked a solid blog called Being an Effective Product Owner. In this blog, he better explains the expectations and or responsibilities of an effective Product Owner including close collaboration with team to guide and direct the team, active management of the backlog (ranking, grooming, etc.), proactively manages stakeholders [expectations], has a thorough understanding of customer needs, and has some knowledge as to how good software is developed. These responsibilities closely resemble the four aspects that Robert Galen outlines in his book, Scrum Product Ownership — Balancing Value from the Inside Out. These four aspects include part Product Manager, part Project Manager, part Leader, and part Business Analyst.

As pointed out by many in the Product Management space, the role of Product Owner is fairly broad and, although many folks like Roman and Robert have done a good job helping to better define the Product Owner, the role itself is often viewed as ambiguous. Let’s face it, in order to be a good Product Owner you are asked to know your customer, have an in-depth knowledge of how the product or project should satisfy the needs of the product, you must represent the product to both internal and external stakeholders, price and support the product/project to ensure profitability, define requirements, answer questions to the team, be a part of elaboration and planning discussions, facilitate discussions between customers and developers, work with industry analysts, plan and schedule, define what is the most important thing, … ok this is getting ridiculous. This is a lot to ask of any one person.

In years past, when organizations made the transition to Agile (specifically Scrum), the Product Owner role typically defaulted to the Product Manager or the Director responsible for a specific service area (e.g. Customer Service Director). This often meant that in addition to your current job, we are going to ask you to make yourself more available to the development team that is building your product or project. In some cases, this worked out fine — but in most, you’ll see that either the stakeholders are not happy or the development team is not happy. This is simply because there is not enough time in the day, not to mention the expectations and requirements are so broad.

Today, it is common place to see the Product Manager or Director be paired up with a Product Owner. The Product Owner role is given to a Business Analyst or Project Manager that has strong subject matter expertise. In some cases, you’ll see titles stay the same and in others, team members actually given the title of Product Owner. These two (maybe more) team members pair up to become the Product Ownership Team. The Product Manager works the external stakeholder needs while the tactical Product Owner works the internal stakeholder needs — specifically working closely with the delivery team. Arlen Bankston of Lithespeed talks about the roles of Strategic Product Owner and Tactical Product Owner in this blog.

productownershipteamThe Product Ownership Team approach helps reduce the time burdens and constraints, while still fulfilling the need of having a role focus on business value. The advantages of this approach are:

  • More brainpower up front to help understand customer needs and align to solutions,
  • Time afforded to thoroughly understand the marketplace,
  • Capacity to satisfy the “on-demand” need to work with the team, and
  • The ability to avoid unnecessary waste due to bottlenecks that result from a poorly maintained backlog.

The possible pitfalls to look out for with this approach are:

  • When the tactical Product Owner is not empowered to make decisions — you will likely end up conversations being conducted through heavy documentation and sign-off processes,
  • A proxy-type relationship that can keep the delivery team from making a connection with the end-customer,
  • The lack of clear vision since the tactical Product Owner my be too far down in the weeds and not able to clearly articulate the big picture, and
  • Without the Product Manager (or Strategic Product Owner) interacting frequently with the team members — trust and a positive rapport does not develop between the business and the delivery team. This can lead to poor morale and underperforming teams and products.

What approach does your organization employ? Do you have a single Product Owner? Or, is Product Ownership comprised of a Team? If it is a team, are there multiple players or just two?

10 Ways to Fail With Agile (Sandy Mamoli)

in Agile/Resources by

This is a Prezi presentation that I stumbled upon that Sandy Mamoli put out there last year. There are many points in this presentation that really ring true and should be noticed. Sandy does a great job laying out the Symptoms and Root Causes (a.k.a. organization smells). Much of these things are obvious, but almost every organization has some resemblance of these 10 ways. See more of Sandy’s work at Nomad8 blog.

1 4 5 6
Go to Top