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.

venkatesh-dust-bins

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.

venkatesh-dots-user-cards

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.

Tesla

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.

Table1new

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 (Satish.Thatte@VersionOne.com) 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.

facilitators

 

 

 

 

 

 

 

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…

agile-teams

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

From Appaloosa to Agile: What is Your Agile Team’s Pattern?

What’s the Story?

It sounded like thunder!  As I looked toward the field, a group of horses came running from behind the barn at what seemed like 100 miles per hour.  They had their necks outstretched, legs reaching as far as possible, and tails lifted high.  Each one was running in sync with the others as if they could run forever.

They turned in a large circle, eventually going back behind the barn just to appear again like before.  After several laps, the horses settled down and grouped together with heads bowed to catch their breath and debrief on the previous activity.  At that point, it struck me that these weren’t average run-of-the-mill pasture horses.  These were Appaloosas, a breed from the great Northwest around the Palouse River area of Southeast Washington, Northeast Oregon, and Western Idaho.

CowboyKlassy

One significant difference about the Appaloosa horse from other breeds such as Quarter Horses or Thoroughbreds is their coat pattern.  Appaloosa.com states it may vary from a solid pattern, meaning no spotting at all, to multi-spotted, to blanket hipped with no spots.  Patterns and markings are extremely varied and found in many sizes and combinations… No two Appaloosas are identically marked.

So what’s your agile team’s pattern?

What does your company’s or agile team’s coat pattern look like?

Do they all look the same with set workstations, hours and policies?  Are the facilities kept nice and tidy with no difference from one area to another?  Is the response usually negative when there is a request to move a desk, panel or board?  Are the walls filled with images that the building decorator selected years ago when it was built?  Does everyone wear the same type of garments or use the same type of mobile phones?  Is everyone on the same schedule?

Part of Mike Cohn’s book “Succeeding with Agile” is related to the impact that facilities have on an organization transitioning to agile.  Things like visibility to both Big Charts and availability of people can help facilitate agile success.

Spotify

For instance…

At Spotify.com, teams are called ‘squads’ and operate as individual startups. They have an awesome workspace including a desk area, a lounge area and a personal ‘huddle’ room.  Almost all walls are whiteboards.  They are also encouraged to have one hack day every second week, which leads to important product innovation.

Ken Schwaber and Jeff Sutherland, creators of the Scrum Framework, list self-organizing as a specific characteristic of the development team – no one should tell the team how to do it.  This has been called the “heart” of agile software development.

Get to the Point

Each agile team is unique.

No two Appaloosas are identically marked and it is the same for agile software development teams. Just like horses in a field with fences, each team has boundaries; however, there should be freedom to move around and make decisions about the workspace and work items without being constrained.  Take a close look at the “Coat Pattern.”  It is this uniqueness, which stimulates innovation and motivates people.  It’s time to start running and create some thunder!

See you around the barn…

 

Posted in Agile Coaching, Agile Management, Agile Methodologies, Agile Teams, Scrum Methodology, Scrum Software | Leave a comment

Transparency in Agile Projects, Not Emperor’s Clothing

Transparency is the Fabric of Agility

Apparently insecurity about expressing truth and transparency is not a new problem.  Published back in 1837 by Hans Christian Andersen, “The Emperor’s New Clothes” accurately describes a phenomenon alive and well today.  In a nutshell, weavers (con men) convince an arrogant ruler who only cared for appearances, that their wonderful new fabric is invisible to those who are stupid or unfit for their position.  The ruler purchases clothes made of this fabric from the weavers so that he can expose those around him who are unfit.  The fear of being viewed as unfit leads the emperor and all those around him to openly admire the new clothes, reinforcing the illusion of widespread support.  It takes an innocent child with no agenda to point out the obvious truth – the emperor is not wearing any clothes.

Yes this analogy has been drawn many times.  We laugh at the story, but do we still fail to see the parallels in our own behaviors?

Cat in a Box

In business projects, the phenomenon looks something like this… The manager brings forth the plan and everybody readily agrees with it despite individually realizing there is little chance of success.  Regularly they parade to status meetings and with great pomp and circumstance, proceed to report how all is good and they will get it done (somehow).  Secretly, nobody including the customer believes this is likely, yet nobody dares to speak of this out of fear of looking incompetent.  Secretly, and then only with their deepest confidants, some will laugh at how clueless others are to actually believe this is workable.  Heck, even the manager doubts it, but won’t admit it either, also for fear of looking unfit.  Much effort goes into maintaining the grand illusion.  This goes on to the point that it is essentially woven into the fabric of the culture as they actually become to believe in false realities. Communal reinforcement becomes the norm.

Emperor New Clothes

Why does this paradigm persist so prominently still?  Why indeed is curious because the results are not good….

Customers lose faith.  Reality is that they rarely get what they really need, when it was promised or for the budget they agreed.

Project teams lose motivation.  They do not want to fail.  Quality suffers in an effort to get something delivered and they suffer burn-out through endless pressure to find a way.  They begin to feel hopeless and overcome by technical debt.  Productivity and morale suffer.

Managers desperately seek to hold it all together and their stress level rises as well.

Curious indeed – why would competent individuals run a business this way?  Reality always wins eventually, though some are good at maintaining the fantasy a long time.  So, why do some individuals enforce such a norm when actually each would prefer the truth?

Well I am not a psychologist.  But logically the behavior seems rooted in an inner insecurity and fear.  Humans are social wanting acceptance from others. Sometimes we assume that others are smarter and thus must be correct, leading us to doubt what we really know.

The larger the group, the harder it is to speak against the perceived majority position. The more challenging the project, the more likely we are to look to others for confirmation and question our own knowledge.  And when a person of recognized authority is setting the tone, the less likely their position will be openly challenged.

We won’t realize the benefits of agile until we face some of the human psychological barriers that inhibit change, even good change.  Logically we can see how agile works.  Yet, it still does not work well in many organizations or at least to its fullest potential.

Real change requires someone to come forward and simply tell the truth about reality.  That simple act alone can start a domino reaction of healthy change in cultural norms.  False realities are fragile and not sustainable long term.  Mere facts, data, and simple truth are their downfall.  Likely most others are not wanting to promote the false norm either, but do not realize that there are others like them.  So, one brave soul really can change everything.

Now ask yourself, is your organization truly transparent?  Are you really sure?  Does the culture promote openness?  Can project members be candid without fear of reprisals?  Cultural barriers to openness and transparency are significant impediments in truly becoming agile.

First clearly reinforce that transparency and openness are core values of your organization.  Set the standard, demonstrate it, and live by it.   Accept nothing less at all levels.  Remove any appearance of negative consequence for openness.  If you find candid response lacking, explore why without condemnation.  Organize people into small project teams as it is easier to be open within a small group (like agile framework promotes).

Maybe your organization just does not have the means to objectively assess true project status without emotional basis?

There is a simple solution and it takes the whole communal reinforcement problem out of play – use an agile project management system to objectively capture real-time project status automatically providing total transparency.  Review project status data pulled in real-time.  Burn-down charts and project dashboards provide immediate real status.  Make sure your teams are committed to accurate tracking and then trust what the data is telling you.  Real data communicates reality.  In Scrum, velocity enables forecasting based on proven performance.  Let measured velocity forecast project results with objective data.  Now nobody feels pressured to provide what they perceive somebody wants as an answer.  Let the facts speak.  Learn to trust the power of velocity.

Let transparency unlock real project team engagement and improve your business agility.

Is project transparency a problem?  Have you seen these behaviors?  Why does it persist?  How did you succeed in changing it?  Please share your comments and observations.

Posted in Agile Adoption, Agile Management, Agile Project Management | Leave a comment

First Things First: Scale Agile Values and Principles

Over the past few years there’s been an interest in scaling agile to the enterprise.  The desire to scale agile seems to have intensified over the last year, in particular.  Almost without exception, every conference remotely related to software development and/or project management seems to have some presentation on the topic of scaling agile.  I believe this is being done with the best of intentions but, in my opinion, it misses the point on at least three levels.

First, almost all of the discussions I’ve heard, and most everything I read, refers to scaling aprocess.  I can understand why so many are looking at the process first—because it’s easier; well, until they actually start at which point they discover it’s not so simple after all.  One of the reasons they immediately encounter difficulty is that the enabling factor of scaling is not yet in place.  I know it may sound cliché at this point, but please recall the first line of the Agile Manifesto which states that we value “individuals and interactions over processes and tools.”  One of the primary reasons companies struggle so mightily with agile adoption, not simply with scaling, is because the enabling behavior and attitudes are either lacking or totally nonexistent.  They’ve either forgotten to consider individuals and their interactions, ignored them completely, or undervalued the importance of the human element.

Agile methods are based on empiricism, which implies adaptation based on observations.  In short, it is not a control mechanism—especially of people.  In fact, I’m beginning to strongly believe we should stop talking about scaling process entirely—at least for the time being; rather, focusing our attention on de-scaling process through the introduction of replicated Lean Startup models such as the one Spotify has adopted.  My colleague, Brian Watson, also discussed this premise in a blog post titled Agile Killed the Project Star.  If you’d like an introduction to the Lean Startup, the video below summarizes the concept .

Secondly, I fear that leaders genuinely desire the results agility promises (faster delivery, higher quality, improved morale, etc.) but do not want to first address their own behavior. They’re perfectly ready and able, but not truly willing. I constantly hear the lip service, but rarely witness the behavior demonstrated. The dissonance I see repeatedly is as follows:

Lip Service: I want teams to be self-organizing, self-sufficient, and deliver value quickly to the customer with high quality;

Behavior Demonstrated: I don’t want to let go of the control I’ve worked so hard for and hold dearly. I must be able to leverage my personal authority – otherwise, what value does my authority bring?

This is a dysfunctional and destructive attitude for your teams, your organization, and your shareholders. For an agile leader, the value of your authority is that you have power to remove organizational and bureaucratic barriers impeding the progress of teams—exercise your authority through servant leadership. It’s amazing the change you’ll see in others as a result of first changing yourself. Reread that sentence again and stop to let it firmly embed itself into your psyche. To put it another way, you do not deliver value; you enable value delivery. I wrote about this topic last year in a blog entry titled What’s Your Role: Umbrella or Funnel?

Finally, when people speak of scaling agile they are usually talking about IT or software development—the technologists. This is about so much more than software development. The agile values and principles offer a promise of a more innovative way of managing and working in a creative era than the hierarchical control mechanisms invented by Frederick Winslow Taylor used to manage Industrial era assembly line work. Unfortunately, this is still the predominant management technology used today.

To extract maximum organizational benefit, consider embracing agile throughout the entire value stream. I’m talking about adoption that begins at front-end sales all the way to back-end support and customer service. The only question is, are you willing to adopt the behaviors and attitudes (as an individual) necessary to enable this type of change?  I’ve created additional content beyond what’s in this blog if you’d like to further explore A Case for Building the Agile Company.

Posted in Agile Adoption, Agile Benefits, Agile Management, Enterprise Agile, Scaling Agile | 6 Comments