So you’re going to be a ScrumMaster?

Team“Well I am a PM now but they are making me a Scrum Master.” I have heard that statement countless times. Some PMs are happy about the new challenge, some aren’t and some just want to keep making those Benjamins. I have to admit even though being an embedded software engineer by trade the ScrumMaster role is my favorite role on a Scrum team. When asked what is a ScrumMaster I always respond with a servant leader and Agile champion for your team. Yes there are more details but I think simple is the best approach sometimes.

I thought it might be a nice time to talk about some of the qualities that a great PM has and how those look in an Agile environment. PMs tend to get a bad wrap from the Agile world so lets clear the air. I just so happen to have a fiancee that is a PM for a large company. She tries to give me a gantt chart for the week and I hand her story cards daily at breakfast. I asked her to take a survey of her peers which consisted of development, product management and other PMs. They came up with five qualities a PM has, here they are in no particular order.

Issue / Risk Assessment
Issue Resolution
Listening Skills
Manage Expectations of the Business
Process Oriented
On the topic of issue/risk assessment I can help your stress level by letting you know that issue assessment and risk assessment take different routes. Issue assessment gets the chance to happen everyday in team’s standup meeting. Of course if this is urgent it may be brought to your attention sooner. Risk assessment is happening all the time by way of the entire team. Is the sprint going to be completed, what stories might be slipping and what can we do as a team to deal with that.

Issue resolution is a key quality that will carry over. As a ScrumMaster you should do everything in your power to resolve issues or impediments for the team. This not only keeps the team adding value all the time it also builds their trust in you as the ScrumMaster. Issue resolution also requires a good listening skill.

Listening is a skill or quality that I think everyone is challenged with in life. Listening before you speak, listening before you start to think of your response etc. ScrumMasters have to fine tune this skill, even when it makes things uncomfortable at times. Some ScrumMasters tried to lead the team too often with words. I am a fan of posing the question and then letting the silence get uncomfortable enough that someone from the team answers. Which breaks the ice and conversation begins to flow. This also starts the baby step path to the team becoming more and more self organized.

Our next quality, managing expectations of the business, which is easier now! You get to manage it two weeks at a time or however long your sprints are. You will work with product owner to sprint plan and release plan if you are making use of that planning method. Better yet, let’s remove manage and add rank. Ranking is what a product owner is doing with the pieces of the value the business is looking for. Your job as a ScrumMaster may be to help the product owner provide details necessary to get the conversation and collaboration going! Those specs are you are used are gone and I challenge you to ensure the story doesn’t turn into a spec.

Being process oriented is good thing since you have new processes to learn. Scrum as a concept isn’t hard to understand but mastering it can take quite some time. That being said a Scrum team can take a year or more to fully mature. A good ScrumMaster is more than a certification, not to knock them. You will have times when you have to figure out the best way to passively guide the team towards better Agile values. You have to truly believe that what you are saying has value and can be successful.

So I go back to my definition, a servant leader and Agile champion. Live everyday for those around you and remember the values that Agile stands for. Go have fun with the rest of the pigs! (Search for it) I’m sure I didn’t paint rainbows and unicorns for the PMs out there reading this. I can assure you the ScrumMaster role will be one of the most challenging and enjoyable roles you’ve ever played on a team.

Posted in Agile Adoption, Agile Coaching, Agile Management, Agile Project Management, Agile Teams, Scrum Development, Scrum Methodology, Uncategorized | 10 Comments

Why Agile Governance Matters at the Project, Program and Portfolio Levels

Guest post by Monte Montoya, cPrime

For any organization attempting to migrate to – or sustain – agile processes, governance is an important consideration. This is especially true as companies grow. While small companies can likely get away with fairly informal governance, larger enterprises cannot function effectively without formal controls in place.

As we touched on recently in the article “How to Develop Your Own Recipe for Agile Governance,” every organization can benefit from developing its own unique “recipes” for agile governance that fit the organization’s specific needs and projects.

But why does governance matter so much? Let’s break the answer down into three categories: the Project, Program and Portfolio levels.

Agile Governance at the PROJECT LEVEL

To keep our terminology clear, we’re considering a project to be “a temporary endeavor undertaken to complete a unique product, service, or result.”

Effective governance at the project level identifies and advocates for specific goals to be reached during each sprint or iteration. It helps determine the core requirements that comprise the initial release of the project and the criteria by which additional goals will be decided upon.

Since multiple projects may be closely interrelated, effective Agile governance is often achieved at the program level where these multiple projects interface with broader business objectives.

Agile Governance at the PROGRAM LEVEL

A program can be defined as “multiple related projects that are managed in a coordinated fashion.”

At the program level, the more comprehensive strategic goals of the organization filter down to individual projects that produce tangible results. Therefore, this is the optimal location for Agile governance to stem from.

Managers at the program level are in a key position to fully understand the requirements of each individual project without being directly responsible for negotiating the details. They are also in a position to understand and translate the overarching strategic goals of the organization to project managers who may otherwise suffer from tunnel vision.

Agile governance also provides managers at the program level the means to monitor and report on the progress of projects under their oversight.

Agile Governance at the PORTFOLIO LEVEL

A portfolio is a collection of programs or projects and other work grouped together to facilitate effective management in order to meet strategic business objectives.”

Managers working at the portfolio level are primarily concerned with organizational strategic goals and may have limited knowledge or understanding of individual project successes or failures. However, they do need to know the general direction in which the company’s projects and programs are headed, and they will concern themselves with business continuity matters such as budget and time line more so than those in project teams.

As utilized by the program level, effective Agile governance allows for clear and measurable monitoring of individual projects and broader programs in a language portfolio managers can understand and work with: time, money, and personnel.

Help For Those with RAGE Issues

Establishing effective Agile governance is a potentially complex and difficult process.

For help in making it happen for your organization, take a moment to review our Recipes for Agile Governance in the Enterprise services.

Learn more about RAGE at the Project, Program and Portfolio levels by checking out our RAGE Introduction Webinar:

Posted in Agile Adoption, Agile Portfolio Management, Enterprise Agile, Scaling Agile | Leave a comment

It Isn’t Agile; It Is Life!

One of the things I like to start with when introducing agile development is the quick application of agile development to life. I ask the question: “Did you plan today six months ago? Did you plan getting out of bed, then taking a shower, then brushing your teeth and then making your lunch, etc.? No, well that’s interesting because I didn’t either.”

However, my mind being an agile machine already figured out my morning in the order that is natural for me. You complete your morning in an order that is natural to you. That’s what the team is trying to do in an agile development environment – add value in an order that makes sense to the user.

My next question, “In life, did you have goals?” Sure you did. You wanted that degree, you wanted a fiancee, a family. Just like Epics are large features or initiatives for products, your life has some large features and initiatives, also!

Now my expansion on that approach…  Bruce Feiler (@BruceFeiler) helped me take that to the next level with his Ted Talk titled “Agile Programming for Your Family.”  I was currently blending a new family: myself with two children and my fiancee with two children (Ages 4, 7, 9, 12).  I decided to put this “stuff” I preach to the test.

I went to the local office supply store and for about $50 I was able to produce four boards for the kids’ rooms.  Keep in mind, I have zero craft skill.  For my four-year-old I used a picture-based board which she could understand, and more elaborate solutions for the older children.  Two examples are below:

Ireland's Board

Austin's Board

With this layout, it is so easy even a four-year-old can do it! If my youngest needs to make her bed, I move the magnet to the frowny-faced girl.  When she is done, she puts the magnet under her picture and if either of us approves, we will move it to our picture. If we do not approve, we explain why and move the magnet back to the frowny-faced girl. Now if I walk into a bedroom and their bed is not made, or their floor is dirty, I simply move the magnet to Not Done.  After a short time I get, “Can you come check my board?” from one of the children.

While we do not do daily standups, we have weekly retrospectives where we all sit on the floor and talk about the week.  What went bad, went well, and what could we improve on?  This is also a great time to congratulate someone or provide a family announcement since we have the children half-time.  The children also get a chance to have a voice and we have a positive environment for change.  The adoption of this approach has made a huge impact on our family.  The older children self-organize (a.k.a., tell on each other) if one of them is slacking; the younger children actually encourage each other and often help each other complete their tasks.  We were finally asked about allowance…

While we don’t like that word – and also like to instill life lessons – we did implement a flat salary that has additional commission benefits. If the children keep their boards up all week without too much parental encouragement, then they receive their salary.  If they go above and beyond the board, they receive a commission.  For example, maybe my nine-year-old vacuums the upstairs without this being a task.  He just realizes it needs to be done and does it.  We make a mental note of that.  Now this is where it gets interesting. During the retrospective we hand out the cash, in all Ones, of course.  We pass it out around the circle. If someone didn’t go above and beyond, they get to hold that extra money as they pass it around the circle until it gets to the rightful owner.  Are we driving behavior? You bet we are!  Positive behavior that if you want something in life, go get it!

While the salary and commission do not have that much to do with agile development, the approach provides us with a mechanism for other teachings which we would like our children to pick up.  So I have Bruce to thank for the success we have had. If you haven’t had a chance to see his talk, I have provided a link below.  I truly believe that agile development is a successful philosophy which any company or family can adopt and be successful!

Agile programming for your family – Bruce Feiler



Posted in Agile Adoption, Agile Benefits, Agile Development, Agile Management, Agile Methodologies | 2 Comments

Changing the Mindset of Agile Teams

Guest post by Venkatesh Krishnamurthy, delivery coach, author, advisor and curator with Techwell

Agile is not about practicing Scrum, XP or Kanban. It is a mindset that one needs to cultivate. It is not about doing a daily standup or retrospective but knowing the values/principles behind it. Most of the agile teams are interested in practices and very few are interested to learn the values/principles.

People resist adopting new values and principles as it expects a change in mindset of teams. Changing the mindset of agile teams is always a bit difficult. I have started believing that it is easier to change the people than their mind. The good news is, there are some tools and tips available to help in this journey of changing mindset.

Let me explain one of the tools with an example. A couple of weeks ago, I came across these two dustbins outside of our apartment complex.


As one could see, one of them a simple open cardboard box and the other one is a proper dustbin. Not sure why they had kept these two together. In the next few days, I noticed that people were throwing wastes mostly into the open box. However, the other one needed additional effort to open the lid to throw the wastes, which was left unused.

What I learned from this experience is, if you want people to follow ideas, make it easier for them to learn and use. Or else they will never change. 

Another case study is from one of my agile projects. The teams were using an agile project management tool which was not so user-friendly. Teams diligently added all the user stories and tracked them on a regular basis. However, when the need came to extract the key metrics like Velocity and Cycle times, the team had to write queries manually and tweak it regularly. They always resisted this manual, cumbersome process, which was time consuming as well. The teams always used to fall behind sharing these critical agile metrics with the stakeholders.


I suggested an alternate approach, which involved adding a dot on the user story cards after their daily standup until it is complete. It looked something like the one shown in the picture below for measuring the cycle times.  They used a simple sketch pen to put the dots on the cards.  This was so much easier, and the team loved it.  After this little change, they never resisted sharing the metrics.

Conclusion: If you want to change the behavior or mindset of agile teams, create an environment that is easier to navigate and use. The non-intuitive tools and processes could be a major blocker in the change journey of your teams.

About Venkatesh

Venkatesh Krishnamurthy is currently working as a delivery coach for a large financial institution in Melbourne, Australia. In the past, he has worked in different capacities from a developer, architect and as a scrummaster. He has designed some of the largest applications, led and built Cloud Center of Excellence, and has managed large-scale distributed teams of more than 150 people. Venkatesh is an author, Agile fellow, and Agile advisor for many companies around the globe. Check out his blog here.

Posted in Agile Adoption, Agile Benefits, Agile Methodologies, Agile Metrics, Agile Teams, Scaling Agile | Leave a comment

Three Agile Styles

Guest post by Allan Kelly, founder of Software Strategy in the UK

From time to time I feel sorry for those coming new to agile. I feel sorry because some of them expect to find agile provides a solution to their problem. For better or worse, agile doesn’t provide a solution but many solutions. The agile toolkit contains many tools which solve many problems in many contexts. But, like showing a customer software, the problems and context only become visible when solutions are seen.

For the last few years, I have found it useful to differentiate three different styles of agile. These styles are independent of any particular method: Scrum, Kanban, Lean, XP, etc. can be used in any of the three styles. Each style addresses similar – but not identical – problems within different contexts. The result is that the solutions, while similar, differ.

Iterative Agile:

The developers and testers are doing lots of good agile stuff: daily standup meetings, fortnightly iterations with planning meetings and retrospectives, small vertical stories and so on. Hopefully they are doing some of the technical practices:  Test Driven Development, Acceptance Test Driven Development, Behavior Driven Development, Continuous Integration and, perhaps, Pair Programming.

As a result, the teams are better.

But the team’s work is still driven by a big requirements document. Someone has set down in advance all of the features and functionality which the team is expected to deliver. The job of the team’s product owner (often a business analyst) is to salami-slice this document into small, vertical stories for the team to build each iteration.

The fact that the team can show a working product every two weeks is irrelevant outside the development team. The business and customers want all or nothing. They have little or no time to look at demonstration – indeed being expected to attend a demo may be seen as an inconvenience.

In Iterative Agile, requirements are turned into code via a series of iterations which are confined to the development team. The wider organization does not want to change. You hear people say things like, “Agile is a delivery mechanism.” They expect agile to deliver more efficient teams, fewer cost overruns, better predictability and meeting deadlines.

Project success – and it is still seen as a project – is defined by how much of the original document is delivered in the time allowed for the money budgeted. Project managers continue to fear “scope creep” and resist attempts to move away from the original requirements document.

Incremental Agile:

At first glance, this style looks a lot like Iterative. There is a big requirements document, there is a business analyst with a bacon slicer, the development team does iterations, and within the iterations is a lot of good agile stuff.

But in this model, business representatives, customers, users and more engage with the team. At the very least, review the software that is produced every two weeks in a demonstration. Feedback is accepted, some of the originally planned work changes, more work is added, but some is also removed. Hopefully the most valuable work is getting done first and the lowest-value work is falling off the end.

Better still, an incremental team may be delivering their product to live, and real users are using fresh software every few weeks. Hence, the business benefits early and value increases incrementally.

This also opens the door for the business analyst to perform post-delivery evaluation on what is built. This in turn allows the salami-slicing process to be better informed and calibrated to deliver more benefit.

However, there is still a requirements document and the team may still be judged on delivering everything by a predetermined date for a predetermined budget. Incremental agile potentially brings the team into conflict with project governance and thus creates tension in the organization.

Over time, the organization may start to adapt to the team. Success can be additive and others may start to change their working ways to fit with the team better – or even copy them.

Alternatively, the organization might kill the team! In fact, I believe in many corporate environments this is a more likely outcome. Incremental teams can be seen as problematic; they don’t stick to the script and they ruffle feathers. Unless they have a protector with sufficient authority and political weight, the team is at risk.

I have come to believe that in a large corporation, Incremental Agile teams are as good as it gets. It is hard to prove or disprove this belief and there will always be a minority who does better, but in a traditional corporate environment.

Evolutionary Agile can best be summarized as, “Don’t give me no requirements document!”

The development team is still doing all the good stuff. They are releasing to live at least every two weeks. The product owner will be more focused on reacting to change and delivering business benefit than delivering a document.

The wider business judges the team’s success not on how much software they have delivered against plan, but on the benefit they have delivered and movement toward some overarching goal.

There will still be a backlog of work to do, but it will start small and grow over time as the product grows. Much, perhaps most, of the backlog will never be implemented simply because the stories with the greatest benefit will squeeze out those with less benefit.

Indeed, in an Evolutionary Agile environment, this is how it should be…

Evolutionary Agile is most naturally at home in startup environments which need to react – pivot! – to survive. Inside the corporate world, the iterative style rules. Few corporations are ready to give up their faith in the big requirements document and forward planning.

In setting out these styles, I am describing what I find – not what should be. Few teams sit down and consciously decide to pursue one style rather than another. Each is a solution to a specific version of the problem: “How do we organize our software development?” within a particular context. And each context is loaded with history.

Having said that any of the three styles can be implemented with any of the agile methods, I do believe that Scrum tends toward the Iterative and Incremental styles while Kanban tends toward Evolutionary. My own Xanpan hybrid, with its planned and unplanned work model, tends toward Incremental.

Which is the “best” style? Well, I try to remain neutral. Each is a rational response to a context. Rather than say one style is “better” than another, I prefer to look at what the organization is trying to achieve and how it got to this point. Then I work to improve within the existing style – or perhaps, nudge the team toward a more appropriate style.

The Incremental style is probably the most common agile style of all. It might be seen as a step from one world to another; the best of both extremes; or perhaps the worst of both.

Yet, I find it hard to disguise my belief that Evolutionary Agile is in some sense superior, better, purer and truer to the original ideas of agile. I must temper my belief with a recognition that in some environments Iterative or Incremental approaches are more appropriate.

Indeed, one can imagine a spectrum with pure Evolutionary Agile at one end, and at the other end is traditional Waterfall development. Iterative Agile and Incremental Agile are just points alone the spectrum.

While I may want teams and organizations to aspire to Evolutionary Agile, it doesn’t really matter what I want. The challenge for teams is to position themselves at the most appropriate point on the spectrum and work effectively given the context of the wider organization within which they exist.

For many teams, simply moving from a poorly performing Waterfall model to Iterative Agile will be an improvement. One may hope they continue their journey along the spectrum, but if the wider organization is not ready to live in an Evolutionary world then the context is not right. And to do so would create more problems than it solves.

I find that these styles and the idea of a spectrum help me understand the world, as they provide the language to discuss it. I hope you also find them as useful.

Posted in Agile Adoption, Agile Development, Agile Methodologies, Agile Teams, Enterprise Agile, Scrum Methodology, Test Driven Development | Leave a comment

The Team-Centered Organization

It took us a long time to make the move to hybrid vehicles, and even longer to electric powered. For decades, the major automobile manufacturers seemed to be ok with the existing state of affairs. Some accused them (and the oil companies) of inhibiting any efforts that moved us away from gasoline-powered vehicles and toward more fuel efficient or alternative technologies. But to their credit, the car companies eventually came around.

Today we’re seeing more and more hybrid and electric cars on the roads than at any other time. You could attribute this to the rising cost of gasoline, the green movement, a desire to be free of the grip of OPEC, a general sense of technological progress and efficiency, or – if you’re like me – all the above.

At the end of the day, it’s a game of survival. Adapt or die.


If you’ve been involved in an agile transition at a large organization, you’ve likely faced a similar fight. Not everyone is so receptive to change. Transitioning to agile methods requires us to evolve. As we look to do so, I believe one of the first areas to examine is the way our organization is structured.

The emphasis on projects has become huge, and as a result, we’ve seen an almost wholesale shift to the ‘balanced matrix’ structure. This is where departments (like Development, QA, User Experience, et al), and project teams work together. The authority sits predominantly with the functional managers of those departments, and to a lesser extent with the project managers (who typically work as part of a PMO department, reporting to another functional manager).  The projects are run by project managers who have limited authority. These project teams are ‘assigned’ folks ‘temporarily’ from the various functional managers for the duration of the project. Once the project is completed, everybody goes back to their safe, little functional silo, or gets assigned out to another project team. This is how most software organizations have been working for the past decade or two. And this is considered by many to be a major improvement.

But this structure doesn’t fit well in an agile organization. In an agile ‘team-centered’ organization, the team is the crucial element, not the project. The teams are assigned projects. This is a fundamental shift to how we’re organized in the balanced matrix structure, where projects were assigned people.

The idea here is that when we allow teams to stay together and gel, they get really good at delivering. This team development takes time, and is necessary and inevitable in order for the team to grow, to face challenges, to tackle problems, to find solutions, to plan work, and to deliver results. Well-gelled teams know their strengths and their weaknesses. They have learned how to communicate with one another and to be more productive. The last thing we want to do is break up what has perhaps taken months or longer to create.

So, in a team-centered structure, Team 1 might have a product owner, scrummaster, a few programmers and a tester. Other teams could have a similar makeup depending on the size of the effort they’re working on. Many larger organizations have the additional roles of chief scrummaster, chief product owner, chief technical owner, and chief QA, but they sit outside the teams – mainly for support purposes.

You’re probably thinking to yourself, “This all sounds good, but where did the functional manager and project manager roles go?”

The project manager role no longer exists as it once did. Many PMs become scrummasters or product owners on scrum teams. If they’re not a good fit for this type of environment, they often become coordinators or managers of larger cross-team integrations, managing things like logistics, scheduling and tracking.

Functional managers no longer delegate work to teams in scrum. They play more of a mentor role… a servant-leader to the team, helping them to grow, learn and get better. As we know, scrum teams are self-organizing. They don’t need to be told what to do or how to do it. Teams look to scrummasters for guidance on things like standards and helping to resolve impediments.

If you’ve changed to a team-centered structure, what has been your experience? Have roles changed as well?

Posted in Agile Management, Agile Teams, Scaling Agile, Scrum Development, Scrum Methodology | 1 Comment

Agile Management: Avoid the “Pretty Swans vs. Ugly Ducklings” Dichotomy

I usually come across two classes of workitems in agile projects as I train, consult and coach clients at VersionOne.

  • Class A workitems: Customer-driven or user-driven  stories, features, epics, business initiatives
  • Class B workitems: By definition, everything else.  Several examples are listed below:
    • Defects fixing work: Defects pushed out from earlier sprints, or reported by users in their production environment while the current sprint work is going on.
    • Porting work: For example, port software from IP v4.0 to v6.0, port software from the existing database system to a different database system, port software to support multiple browsers, etc.
    • Spikes: Proofs of concept, prototypes and experiments to reduce the technical risk and gain knowledge
    • Develop test suites: Develop automated or manual test suites for various non-functional system-wide requirements, such as performance tests, usability tests, security tests, inter-operability tests, scalability tests, availability tests, system tests, etc.
    • Run test sets:  Run test suites (automated or manual) for various non-functional system-wide requirements listed above; run manual or automated regression tests sets; log defects found along with steps to reproduce the defects.
    • Architecture runway work: Technical infrastructure design and coding effort necessary to support upcoming features in the nearer-term without excessive, delay-causing redesign. This type of work is becoming increasingly important as agile projects scale up. For further details, see the SAFe web site.
    • Infrastructure work: Set up or improve development, test, build environments; continuous integration server; continuous delivery (DevOps) systems, etc.
    • Dependency management work
    • Online help, tutorials, release notes
    • Technical debt reduction work
    • Customer support team training
    • General Availability (GA) release packaging

Often Class B work may represent as much as 30% of the total work if it is fully accounted for and properly estimated. For so-called hardening or stabilization sprints, all work is Class B work. However, Class B workitems are often not properly inventoried and logged in the agile application lifecycle management (agile ALM) tool; they are poorly estimated and poorly planned. Consequently, they come back and haunt the team during sprints as unplanned or underestimated work – sort of their revenge for not receiving the respect they deserve. These two classes of workitems are compared and contrasted in Table 1.


Treat all workitems as pretty swans deserving your full attention

No workitem should be treated as an ugly duckling. Here are several concrete steps I would like to recommend so you can treat all workitems as pretty swans:

Ownership:  If the product owner is reluctant to own or support Class B workitems, or does not have a good understanding of them, team members should have an honest discussion with the product owner about the reasons, cost and benefits of Class B workitems. The discussion has to be along the lines that if we don’t take proper care of Class B workitems, the team will continue to increase its technical debt and end up lowering productivity in the future. In fact some Class B work (such as defect fixing and running test suites) even has impact on users. On the other hand, if we spend reasonable effort on Class B workitems (10% to 20% in our view), it will lay the foundation for productivity growth in the future. If necessary, senior management (perhaps facilitated by the ScrumMaster) may need to play a constructive role here, as there is never-ending pressure to deliver more and more Class A stories demanded (or thought to be needed) by customers and users.

Inventory and Visibility: There must be a full and proper inventory of all Class B workitems. They need to be logged into the agile ALM database with clear and complete description along with appropriate acceptance criteria.

Analysis: The analysis methods for Class A vs. Class B workitems are different. The product owner or business analyst explains and clarify Class A workitems.  Team leads (development leads, QA testing leads) and other subject matter experts clarify various Class B workitems.  Analysis of both Class A and Class B workitems should be done preferably one time-box ahead of their design and development time-box, as explained in my sprint pipeline blog post. Only with proper analysis effort can one clearly understand what needs to be done for each Class B workitem — the prerequisite for estimating, planning and the actual implementation effort.

INVESTment: Class B workitems also need proper INVESTment. They need to be independent of each other (at least the specification level). They should be negotiable between the product owner and the team, with both sides coming to an agreement on the scope of the work and what is outside of the scope. Although the value for some of the Class B workitems (such as spikes, architecture runway and technical debt reduction) is not immediately relevant to customers or users, the product owner needs to understand this work is important to reduce the technical risk and to improve the productivity (velocity) of future sprints. The team members should be able to break down large Class B workitems into smaller Class B workitems that can be completed in a single sprint. Each workitem needs to be testable.

Acceptance criteria and acceptance tests: Class B workitems must have acceptance criteria as agreed upon between their owners and the team, with concurrence from the product owner. Depending on the nature of the workitem, acceptance tests may be a matter of going through a checklist (for completion of release packaging or training the customer support team). Or it may be running and passing test sets, fixing, verifying and closing defects, checking that the spikes have produced the desired technical information (or if you’ve run out of the allocated time for the spike), online help is reviewed to match with working software, etc.

Estimation of effort: This creates challenges for Class B workitems. The practice of estimating Class A stories in story points using Planning Poker or the Table-top estimation method is quite common. But what about estimating all Class B workitems?  Relative size estimation is a powerful technique, but it needs to be applied to stories of the same or comparable type so you can do a sensible apple-to-apple comparison in estimating relative sizes. If you compare relative sizes of disparate types of workitems — such as comparing stories with defects, stories with porting work, spikes with technical debt reduction, or test automation with training/online help — the comparison and resulting story point estimates will not be very meaningful. This is one of the reasons why some teams don’t bother to estimate Class B workitems, which is a mistake, as explained above.

I suggest that a team simply estimate the work effort for each Class B workitem in ideal hours, either based on the team consensus or based on estimation by experts in the team who are likely to do that specific workitem, such as a spike, porting work or online help.  Many Class B workitems do need specialized expertise and it makes sense for the team member(s) to do that work to estimate it. This is a more appropriate way to estimate the effort than using relative size estimation to compare non-comparable workitems (it would be analogous to comparing apples to oranges or comparing apples to other objects like tires or stones).

Once a Class B workitem is estimated in ideal hours, it is very easy to convert that estimate into normalized story points by dividing the estimate in ideal hours by the Normalization Basis chosen by the enterprise, as explained in Part 4 of my blog series on the topic of Scalable estimation and Normalization of story points.

Normalized story point (NSP) = Estimate in ideal hours / Normalization Basis

For example, if the Normalization Basis is chosen to be 20 hours for an enterprise, then a defect estimated to take 4 hours to fix, verify and close is equivalent to 4/20 = 0.2 NSP. A spike estimated or budged to take 30 hours is equivalent to 30/20 = 1.5 NSP. And a porting effort estimated to take 120 ideal hours is equivalent to 120/20 = 6 NSP.

All Class A story points are also converted into NSPs as described in detail in my blog series on the topic of Scalable Estimation and Normalization of Story Points.

Now all Class A and Class B stories will have the same scale for expressing their estimates, i.e., normalized story points. This will make all story point math, reports, and metric meaningful and accurate.

Planning: Sprint planning must take into account both Class A and B workitems. After analysis and estimation steps, planning involves making sure that the planned work is consistent with historical velocity or available capacity. Let’s say the team has exhibited a stable average velocity of 25 (normalized) story points over the last 3 to 4 sprints comprising of both Class A and B workitems. Then under the so-called “Yesterday’s Weather Model” (same team members, same technology platform, same application domain, etc.), the team should plan on undertaking about 25 normalized story points worth of work (comprising of both Class A and B workitems) in the upcoming sprint being planned. If the Yesterday’s Weather Model is not applicable, the team will need to do capacity-based planning considering how the team capacity will be used to perform both Class A and B workitems. The product owner should rank-order the entire sprint backlog of both Class A and B workitems using the ranking method of his or her choice.

Status of Workitems: As all workitems of Class A and B are treated on the equal footing as explained above, all workitems are pretty swans. There should be no ugly ducklings. Planning, execution and retrospectives will all benefit from this approach.  And the teams, projects and organization can only benefit.

Do you have any ugly ducklings in your agile project backlog? Can you think of any ugly ducklings that are not included in the Class B workitems list? Remember that ugly ducklings often have a disruptive effect on the well-planned work for pretty swans. Ugly ducklings can turn pretty swans into ugly ducklings, too.

Do resolve to treat all your workitems (both Class A and B) as pretty swans. From your team’s successive sprint retrospectives, your team should be able to judge whether the problems caused by ugly ducklings are going down steadily, sprint by sprint; if not, what corrective actions must the team take?  Many corrective actions are presented in this blog (see the concrete steps presented above).  In short, avoid the pretty swans vs. ugly ducklings dichotomy.

I would love to hear from you either here or by email ( or on Twitter (@smthatte).

Posted in Agile Adoption, Agile Coaching, Agile Management, Agile Methodologies, Agile Teams, Agile Tools, Agile Training, Agile Velocity, Iterative Development | Leave a comment

5 Steps to a More Agile Organization

Guest post by Arlen Bankston of Lithespeed

What keeps most organizations from true agility?  The most common cause is a lack of holism; agility exists as a development aid alone. It is practiced to the degree possible by IT groups, while ignored, avoided or actively opposed by other organizational entities.   Does this story sound familiar?

  • Several teams have done well using agile
  • There is a feeling agile could be applied more broadly
  • But resource management, metrics, audit and compliance, team structures, customer engagement model, HR practices and more are all aligned for waterfall delivery…

While even in this scenario, benefits can ensue at a local level. The organization itself will never realize the full ability to learn, adapt and execute which end-to-end agility can bring.  Cultural change management is challenging in general, but especially when so many groups are impacted at once.

Here are 5 steps that can help you create a more agile organization:

  1. Build your people
  2. Make your adoption agile
  3. Focus at all levels
  4. Make space for innovation
  5. Refer to frameworks; don’t rely on them

Build your people

Many will remember that the first principle of the Agile Manifesto is “individuals and interactions over processes and tools.”  An outsider looking at many agile adoptions might see the opposite emphasis, as the methods and tools that support them take center stage.  True agility relies heavily on local knowledge, willingness to learn, mental engagement and empowerment, all of which require people with a belief that these methods will make their lives and careers better.

The first step is properly leveraging management.  Functional managers, often given short shrift in agile adoptions, can play a key role in helping to build and support their people through these changes.  Their responsibilities include providing local descriptions of expected skill sets and competencies for hiring and progression; implementing and supporting role-specific tool sets; setting up communities of practice (CoPs) to support collaboration across teams; and managing performance through frequent feedback loops and reviews.

The second step is creating clear career progressions.  New roles like ScrumMaster and Product Owner need to be defined, supported and provided with growth paths, while existing positions like Development and Quality Assurance may need to be modified to better fit their agile incarnations.  One popular model is the “Teaching Hospital,” where employees progress through 3 broad stages of mastery:

  1. Learning – Acquire knowledge by being a student and mentee.  Example: A developer takes Agile Engineering 101 training and a few platform-specific classes to fulfill the objectives of this level.
  2. Practicing – Acquire real-world experience.  Example: A developer works on a Scrum or Kanban project for a minimum of 6 months.
  3. Teaching – Prove and advance expertise by teaching others.  Example: A developer teaches at least 3 Agile Engineering 101 sessions and coaches an apprentice to a Practicing Level of expertise.

Making your adoption agile

While we need to think holistically, changing everything may take years – and you won’t get it perfect the first time.  The trick is to start with a wide path and get everyone aligned on goals, principles and a basic approach, deepening adoption over time.  There are several core facets to this iterative approach.

Educate, align and assess

Take a week or two to educate a wide band of the organization on the principles and practices of agile, and align on the goals of the adoption.  Executive and organizational overview sessions can create a common baseline of understanding about both the benefits and challenges of lean and agile methods.

Following this introductory training, you can use assessment workshops with senior and middle management, engineering teams, operations, PMOs, HR and so on. This can help to draw out objectives, key concerns and potential near-term solutions for each impacted group. These will also yield a list of perceived risks and issues; a short-term set of pilot initiatives in which to test changes in a controlled environment; and a measurement system to gauge progress of the overall adoption.

Establish accountable adoption teams

Big changes require dedicated attention, so set up teams to manage the adoption like a project itself.  These typically consist of an Executive Agile Steering Group which sets broad organizational goals and defines measures of success, and an Agile Working Group which helps drive and monitor the adoption.

The Executive Agile Steering Group might meet on a monthly or quarterly basis to review progress, communicate changes in organizational focus, and address high-level impediments noted by the Agile Working Group.

The Agile Working Group is a cross-functional problem-solving group generally consisting of representatives from development, QA, production ops, analysis groups, PMOs, and middle management.  Their job is to anticipate, uncover and address tactical issues within and between active agile teams, making recommendations to executive teams as appropriate.  They also gather metrics and manage communication about the adoption at both team and executive levels.

Focus at all levels

Doing more than one thing at a time results in multitasking and context switching, which can dramatically lower both efficiency and quality. Most organizations are severely overburdened at all levels, encouraging teams and individuals to juggle multiple projects at once and causing a dilution of focus.

Toning your organization’s project portfolio can bring immediate and substantial benefits to time to market, quality and satisfaction.  Some good places to start:

  • Terminate sick projects – There are always projects that seem to be going nowhere, but the political capital behind them won’t let them die.  Be ruthless in killing these boondoggles.
  • Limit development timeframe to months – The ability to release more frequently is a key component of business agility; avoid the temptation to keep releases long due to overhead. Instead, focus on making the release process more efficient.

Letting your teams focus on one thing at a time is especially important when you’re also asking them to learn and implement a new method.  Additionally, this yields a much clearer sense of true team capacity over time, as project delivery metrics aren’t confounded by multiple intersecting workstreams.  Align teams by platforms or lines of business, then let them deliver one project at a time while PMOs line up the next by business priority.  Limit work in process at the portfolio level to improve both the cycle time of individual initiatives, and the total volume of initiatives delivered each year.  Stop starting projects, and start finishing them.

Make space for innovation

Agile methods focus on making change cheap, so that organizations can experiment without fear.  However, true innovation tends to fail often before it succeeds. So the portfolio management process must take account of this reality and create space for exploration.

The “Lean Startup” method offers a number of tools and principles for managing product development in an iterative and incremental manner.  Key among these is to regard projects as sets of small experiments, where for instance each Sprint would have expected results that can be compared against observed reality through metrics.  Another idea is to have teams more directly engage with real users and customers by “getting out of the building,” which creates a richer, faster feedback loop and avoids organizational navel-gazing.

One other key consideration is how financial management processes such as project budgeting, reporting and contracting are affected by agile methods.  One theme here is that adaptive organizations need to allow for incremental funding and iterative scope changes. This means that typical fixed annual budgeting cycles are too lengthy and restrictive for agile environments.  Quarterly budgeting can help here, informed by clear guidance on when to increase or reduce funding that is reviewed and applied regularly across the project portfolio.  Public organizations also must develop accounting rules that explicitly determine whether and when software projects are capitalized — a process that can be unnecessarily restrictive to change if not appropriately tuned to the rapidly changing nature of innovative projects.

Refer to frameworks; don’t rely on them

The human predilection for easy answers leads many to turn to reference frameworks for adopting and scaling agile methods, such as Scrum and the Scaled Agile Framework® (SAFe™).  These patterns are of course quite useful, offering us guidance on what has worked for others, but attaching an organization too tightly to any specific methodology is a mistake.

True agility is by definition the ability to adapt; thereby, the concept of “one best way” is absolute anathema to this objective.  The right way to approach these frameworks is to pick the simplest one that seems to fit your situation, then adopt complementary methods over time, emphasizing the realization of desired outcomes over process adherence.

For instance, Scrum is a good starting template for team formation.  Kanban is great for operations and maintenance. And SAFe offers guidance for organizations running large initiatives with many dependent teams.  However, none of these is truly universally applicable, nor are they mutually exclusive. For instance, Scrum might be too restrictive, Kanban too open-ended to drive real change, and SAFe overly complex for many environments.  However, a nice cocktail of SAFe for agile program and portfolio management, a Scrum/Kanban/XP hybrid for team delivery and Lean Startup techniques applied to product management might work very nicely.

There is no single best practice in agile methods, and those who have been paying attention will have noted that the methods themselves have evolved substantially over time.  Don’t be a zealot; these approaches are simply a means to the end of being more flexible, fast and effective.  So focus on those goals and adjust your practices over time to meet them.

Posted in Agile Adoption, Agile Methodologies, Agile Portfolio Management, Kanban, Lean, Scrum Methodology | Leave a comment

Missing Scrum Value: Accountability

Guest post by Manny Segarra, Warrior ScrumMaster at Truven Health Analytics

How can WE all go forward if YOU won’t come?

Finger pointing, blame game, and throwing people under the bus are classic strategies for self-preservation. It’s just easier to shed responsibility then to explain our failures. The habit of not placing blame or responsibility where it belongs is pervasive.

For example, tobacco companies were sued because smokers got cancer. Bars get sued because their patrons were charged with DUIs. And fast-food chains get the blame for our health issues. Agile has the core value of commitment, but that is an outward-facing concept: commit to the sprint backlog, commit to your team, commit to delivering value to the customer. We must first look at ourselves and when you turn commitment inward, you have accountability.

There must be group accountability mindset where responsibility, reward and failure are shared by everyone. It would be ill-advised to continue the old mindset of “it’s not my job/customer/project/etc.” The satisfaction of the customer and delivering value to said customer is the responsibility of all. If we work for the same company, how can we ALL not be held accountable for failure?

Start at the bottom and work your way up, but… start with yourself

Some companies have not bought into the agile “fad.” Others fake agile well and some will never understand the intent. Regardless of your position, you cannot think one way and behave another. That’s hypocrisy (see Washington, DC). Accountability begins with a promise for you, to yourself!

Each of the 5 Scrum values can be drawn back to you and how you apply them. There is no shortcut. Accountability demands you honor your commitment to the team and demonstrate courage to speak up when team agreements are not honored. How can we respect each other if we do not hold each other accountable for wrong behaviors? If we take our focus off the sprint backlog and scrum value, how can we blame someone else? If we are not transparent in our words and deeds, where does that accountability fall?

3 levels for accountability

A new perspective on an old metaphor, the automobile. The driver is the strategic level of the company, deciding on direction. Management will be the tactical level, represented by the engine. The operational level (the development teams) will be the tires, where the ‘rubber hits the road.’ Let’s start at the bottom and see how accountability works its way up.

Operational accountability

Companies want the performance of Pirelli tires from their teams. High-performance tires cost a lot but are worth it in the long run. For teams to be like Pirellis, they must be trained on the technology stacks with which they work, be given time to gel, work through some projects together – both good and bad, have the environment to thrive (team rooms, colocation, dedicated product owner and ScrumMaster), in a culture of learning. These things empower teams to perform like Pirellis, to produce the quality everyone deserves and customers demand.

What kind of performance can we expect from tires? Tires are accountable for the following: a smooth ride, handling well in tight corners and traction on tough road conditions. That translates to predictable delivery, quality-tested code (high-quality tests AND code), and the ability to respond to obstacles (roadblocks!). No one faults the tires when the direction constantly changes (too many projects). Tires can be blamed for not handling a sharp turn, unless too much speed is applied (scope creep)!

Accountability for the teams means making sure the team responds to the inputs from the engine and the driver to ensure that the car arrives safely to its destination, which is the end of the sprint. Teams must be sure to adhere to the rules of the road (team agreements), honor the speed limit (established velocity) and, if possible, avoid blowouts (not honoring the sprint commit!). All of these things are within our control and we must be accountable for them. Of course, a tire can perform better with…

Tactical accountability

How does the engine affect the performance of the tires? Well, when was the last time you took a hairpin turn, at night, in the rain, jerking the wheel hard to the left, while accelerating through the turn?! I do not believe even Pirellis can guarantee your safety in that scenario! But is that not how we drive our scrum teams… changing direction while demanding more velocity?

Management is the engine, responding to the needs of the driver, but not at the expense of the tires. In NASCAR, there is a piece of the engine that DOES exert influence and control of the driver. It is called a ‘restrictor plate.’ It limits the amount of gas that’s delivered to the engine, not allowing the car to go beyond a certain speed. This is what’s needed to control or hold to account the actions of the driver so that the whole car can perform, within limits, to finish the race.

The engine must be tuned and provided with replacement parts when necessary. How does this translate to accountability? Management must be accountable for throttling the power (number the projects) which teams are working on. The tuning of the engine is performed through portfolio management, agile coaching and training, to ensure all the parts of the engine are working in harmony.

Accountability is represented by emulating a well-oiled machine, meaning setting the example of high performance; a smooth hum of operation (consistent messaging), delivering torque to the tires (empowerment) and not allowing the driver to exceed speed limit (the velocity/capacity of teams).

The engine also provides feedback to the driver through the dashboard instruments. Temperature can be represented by morale, the speedometer (obvious!), gas consumption (steady pace), etc. The engine is the interface between the Driver and the Tires and should be accountable for the smooth transfer of inputs and outputs, between the two elements. Management is also in the unenviable position of responding to both levels, please keep this in mind and be kind!

Strategic accountability

Finally, the direction of the car is set by the driver. The driver turns the wheel and the car responds. When a car leaves Point A and travels to Point B, its common knowledge that a straight line is the shortest distance between these points. When “Speed-to-market” is the goal, why does the driver not hold the wheel straight? Why does the driver steer the car through an obstacle course, swerving to do Project B, around the cones to accommodate Project C all the while, expecting to arrive on time, with Project A?

Strategic accountability is set with clear direction and goals for the company. The driver is responsible for selecting which destinations are most important and keeping distractions (more projects!) to a minimum. Too many stops along the way (delays in decision making, delivery of equipment, not replacing a blown tire!) slow the trip. Focus on the destination keeps the car straight. A roadmap may help but try to know where you are going so you don’t have to read the map while you’re driving!

Look in the (rear-view) mirror

When you look in the rear-view mirror, it helps to see where you’ve been and what might be coming up behind you, but it does not assist in going forward. Accountability can take the form of a map! A map is a plan, at the sprint, release or portfolio levels. The key here is that everyone gets to look at the map and determine where best they can make the trip faster and easier. The way to help everyone is to share the map and make the destination transparent.

Looking into the mirror is another way of saying that you are accountable to yourself and every other part of the car that is depending on your efforts and desire to make the trip safely, on time, and arrive at the chosen destination.

What to do

If we step out of the automobile analogy and back into reality, how can we apply accountability in your company? This time let’s start at the top. Accountability for organizing the portfolio of projects lies at the strategic level. Poor planning will roll downhill and affect the tactical level with too much demand, without the proper capacity to match it. Management will have no choice but to schedule competing priorities, with many projects labeled as “most important.”

The operational level will be tasked to “work smarter, not harder” and that usually means overtime! Accountability at the strategic level is selecting business value and clearly communicating expectations and providing space for adjustments based on input from teams, clients, data driven decisions and other stakeholders. The best map in the world does not guarantee your safe arrival at your chosen destination, so be prepared for detours!

Accountability at the tactical level involves coordination between the plan and the teams, getting the operational level to see the map through the eyes of the strategic level. Adjustments to the plan are communicated down but management must be able to adjust plans upwards as well. Remember, you cannot always follow the map, as the map does not show construction projects, road closures or recently added roadways; we must have the ability to steer the plan according to conditions on the ground. Accountability applies to management by modeling the change in behavior they wish to see take root in the company. This allows the “social safe space” that’s needed for the operational changes to have lasting impact.

Finally, accountability at the operational level relies on teamwork:

Each member of the team is responsible for modifying behavior, collaborating between teams and management, right-sizing the work, adhering to coding standards, delivering on time, holding quality and morale high, addressing bad behaviors, molding their own mindsets, lending a hand to unblock problems, and adjusting to changes on the fly!

Quite the load of accountability here! When teams are overwhelmed with these responsibilities, revisiting the Scrum values, the roadmap, and applying their share of accountability can enable our arrival at the chosen destination!

Drive safe!


Posted in Agile Coaching, Agile Management, Agile Portfolio Management, Agile Project Management, Agile Teams, Scrum Development | Leave a comment

The Role of Functional Managers in Agile: From Tactical to Strategic

Guest post by Sally Elatta of Agile Transformation, Inc.

The Management Challenge

It’s well known that most managers are promoted to higher positions because of their specialized skills and their ability to solve problems well. Basically they were high-performing individual contributors (or at least we hope so).

mgmt challenge

The interesting part here is most new managers attempt to show their team members how to solve these problems by describing how they did it. This makes sense because they’ve done their jobs before and learned lessons doing so. The challenge now is that the real value of a leader is his/her ability to coach others on how to solve problems themselves. This means setting a clear vision, defining acceptance criteria and letting them figure out the ‘how.’ Yes, some gentle nudging is used, especially when a team or individual is new, but some level of mistakes are tolerated and even anticipated. This also means learning to ‘trust’ that your team can self-organize and figure out how to achieve the goals. This idea of creating self-organizing teams is the hardest to grasp for managers who are used to directing at a detailed level what each person on the team does.









It’s interesting… The role of a functional manager is actually pretty confusing because it depends on the personality, interest and skills of the manager playing the role and the expectations set by leadership. Let me illustrate what I mean…


The focus areas above don’t even cover it all. There is ‘administrative’ work which mangers do in addition to ‘strategic’ and ‘cross-functional’ meetings related to active and future projects they attend (sometimes these can take up all the time!).

The Agile Shift

Let’s walk through a quick view of how agile changes some of the areas above.

Work Management and Fire Fighting

This is now managed by the ScrumMaster and the cross-functional team. This is a hard shift for many managers who spend almost all their time managing tasks, getting statuses, redirecting what people were working on, and responding to the daily fires and impediments.

Subject Matter Expert

Every agile team has Solution Leads who are technical or Business Leads who are subject matter experts advising the team and who can translate the business vision into a technical vision. They work as part of the team (dedicated or shared) to provide guidance and direction when needed, in addition to mentor and transfer knowledge to those who want to grow.

People Development

This still remains the focus for managers with a bigger emphasis now than before on the individual coaching aspect. To be honest, most managers were so consumed on managing the work that many of them have had no time to develop their people or learn the critical skills of coaching others. Many teams have put up with various behavioral dysfunctions because managers have been too busy or not skilled enough to deliver behavioral coaching with individuals or teams.

Process Improvement

Again, this is another area that many times gets neglected because of the focus on work management and fire fighting. Agile advocates creating Communities of Practice (CoPs), where people can come together and share knowledge, develop standards, identify and resolve impediments, select and learn tools, and help each other within a specific functional or focus area. Managers can be great leaders for these CoPs and can help bring people together to improve the processes for their teams and at the enterprise level.

Usually team members allocate time each week to attend these CoP meetings, which should be working sessions that deliver real value. In addition to the functional CoPs, managers are now creating a CoP for managers, where they work together as a team on related ‘Process Improvement’ backlogs.

Summary and Final Thoughts

sally-elatta-agile-transformationAs I’ve worked with many companies through their agile transformation it has become clear to me and to the leaders of these organizations that there is a need for a real transformation to the role of functional managers. Agile takes away the tactical focus many managers had and provides the opportunity now for real strategic shift by focusing on the people development, process improvement and beginning to learn the skills of strategic thinking and planning.

The real challenge is many managers are so used to being in the day-to-day details and managing the work level that this shift might be difficult, if not impossible, for some. It makes sense to put managers in the role that fits them best. So find for them a work management-related role such as Program Manager, Solution Lead, Architect, Systems/Business Advisor, etc. and grow the managers who are passionate about developing people into the resource manager role.

Posted in Agile Adoption, Agile Coaching, Agile Management, Agile Teams | 6 Comments