Introducing a full agile framework can be daunting and cumbersome. Instead, try beginning with the method's core focus: continuous improvement. Retrospectives are the starting point of your agile journey and can help you solve the most immediate problems in your process, leading you down the road of process improvement.
More and more companies realize that focusing on cost savings alone is no longer good enough in today’s fast-paced world. In a competitive landscape where customers have many more options and smaller startups can easily disrupt giants, we need to shift to a value-focused mindset to remain competitive.
Value management in a portfolio context refers to strategic business value (more than the aggregate value of a collection of user stories.) Portfolio-level agility is about optimizing the delivery of that business value.
We introduced the concept of value management in "Portfolio Management for the Fast-Paced World":
“Value management asserts what value is, so we can look at the entire Lean perspective of 'concept to cash' in a value stream. This supports both a more traditional scoring model and benefits realization, as well as approaches like Lean Startup’s Build-Measure-Learn cycle. This pillar represents the portfolio demand -- the demand for development work. “
Value management is a hot topic and we'll be writing about it in the coming months. It’s also an area in which the industry has few experts so engaging with those experts wherever you can is a great way to advance your expertise.
Here's the expertise you should gain if you’re accountable for defining value:
- Adopting methods to detect business opportunities
- Defining market sizing
- Forecasting revenues in new markets
- Understanding existing customer alternatives to get their job done
- Building lightweight business cases
- Picking the “right” things to build from the many possibilities
- Measuring post-delivery value by understanding net lifecycle profits
The problem is that in a fast-paced world, there’s no time to do all those things at a level of detail prescribed in traditional product management curricula. Just as new principles of capacity planning are called for, Value management needs new ways to keep up with the accelerated rate of business. Product management practices must evolve to meet the modern needs of value management.
Agile and Lean practices are popular because they keep pace with the rate of today’s business. Applied to product management, these practices help us retool our product management practices with lighter-weight processes. For instance, minimum viable business cases help us adopt incremental funding methods to redirect funding where more value can be delivered. By the time you write a traditional business case, the opportunity may be gone. Instead, think of applying the continuous cadence planning principle to value management.
In product companies, the product manager role has historically been responsible for defining value as a set of features. In IT, line of business managers and business analysts have been the more common roles, although IT groups could greatly benefit from taking a product lifecycle approach to their work. (Topic for another blog….)
As value receives a bigger focus in organizations looking for greater business agility, various levels and dimensions of value come into play and more roles get involved in value definition. For instance, product manager and product owner are two distinct roles, each having an integral contribution to defining value: product managers define the right features to build, and product owners define how to build the features right. Together they can “Build the Right Thing" and "Build the Thing, Right”. Other roles involved in value definition include business leaders, who track which markets are worth doubling down on; and portfolio managers, who balance longer-term value with shorter-term wins.
The Scaled Agile Framework® (SAFe) has pushed the industry to take a big step forward by making a clear distinction between the product manager role and the product owner role, addressing a pitfall we documented several years ago: when development first adopts Agile practices, there's a propensity to reallocate existing product managers to the product owner role, inadvertently equating the two roles. Merging these two roles causes an organization to lose sight of the evolving business value Agile teams are expected to deliver to their business stakeholders. Prioritization then focuses on what we can do rather than what we should do, and that undermines an organization’s ability to match demand and supply, which maximizes value delivery. Thank you, SAFe, for distinguishing between the two product roles!
However, SAFe and other scaled Agile practices still come up short in guiding organizations on how to define value, and gain the expertise listed above. That’s why we’ve added Building the Right Thing to our Agile University offerings.
The class is taught by expert Linda Merrick from Rally partner Pivotal Product Management. Linda has over 29 years of product management expertise, with a deep understanding of Agile product management. Her class covers the various roles and dimensions of value definition and helps you build the capabilities your organization must acquire to reliably define value, so that development efforts are spent on building the right products and applications. For IT environments, the class also offers practical advice for taking a product approach to IT, a key factor for IT groups delivering business value.
As you enjoy the end of the summer, don’t pass on the opportunity to bring these capabilities into your organization. You may find yourself better equipped to answer the question, “What should we focus on next year?” Our next Building The Right Thing classes take place Sept 9 in gorgeous Boulder, Colorado, and Oct 14 in (not bad either) Raleigh, North Carolina. Take the opportunity to visit our Rally offices during the class breaks!
Wondering how innovation fits into value management? Browse our interactive Enterprise Lean Startup overview.Catherine Connor
It was a normal day. I was reading articles, blogs, emails, Tweets, stories and a host of other types of information. While perusing an item, there was an interesting link and I clicked into another Web location. When I arrived, the newly presented topic was not what I expected so I navigated away from the site. Little did I know, this interaction was most likely recorded by Google Analytics as a “Bounce.”
Google states that, “Analytics helps you analyze visitor traffic and paint a complete picture of your audience and their needs.” Things like Page Views, Average Time on a Page, Entrances and Exits are tracked for behavior. However, the most interesting metric could be the Bounce Rate.
“The Bounce Rate is the percentage of single-page sessions (i.e., sessions in which the person left your site from the entrance page without interacting with the page).” In other words, they were attracted to a specific page and when they arrived, they left the site without interaction. The lower the “Bounce Rate,” the longer they interacted with the page and the site. According to Google, “If you could only choose one metric to look at, Bounce Rate might be your best choice.”
So how does this relate to agile development and agile success? Similar to a Web page or site interaction, a team with a high “Bounce” rate will not be as productive as one that is stable and has stayed together through more than just a short introduction. When people are added or removed on a regular basis, there is not time to understand the full scope of work or the people involved in it.
Medinilla states, “The principle of assigning projects to teams assumes that some team stability is needed. If you are changing team composition every 2 weeks, you are essentially managing a resource pool in disguise. On the other hand, if you are using agile development’s definition of a ‘team, ‘which is more than a group of people commissioned to do the same job, you’ll need some time for the team to ‘glue’ or, as some experts call it, ‘gel together.’” (Medinilla, 2012) It is this unnecessary change, or “Bouncing” that causes confusion, demotivation and poor results in the area of agile success.
There are many benefits to making an agile team stable, one of which is learning. Alistair Cockburn (2006) asserts, “Novices don’t stay novices forever. People who are novices on one project become experienced by the end of the same project… This ability to learn along the way helps many projects. Within a single project’s timeframe, the people learn new technology, new problem domain, new process, and how to work with new colleagues. Often an agile team struggles through the first 2 increments, becoming stronger and stronger until successful results at the end are almost a given.” Bouncing from team to team and project to project doesn’t allow enough time to learn technologies, domain knowledge, processes and characteristics of people.
To help track the Bounce Rate of your agile team, Ekas & Will (2013) have recommended a metric: “Validate that you have a whole team; track the team membership each iteration, beginning with the first iteration; and review it regularly. Confirm that the whole team starts together and finishes together… if the goal is to have stable, dedicated agile teams, then having an indicator immediately available to confirm that this happens can be a big incentive.“
For example: A team of 5 people starts Iteration 1 with a whole team and completes it with the same 5 people so the Team Bounce Rate is 0%. Iteration 2 starts with 5 but ends with 4 so the Team Bounce Rate is 20% and the Team Bounce Rate trend after 2 iterations is 10%. Compare this trend to velocity or throughput after each cycle for evidence of them being connected.
Success with agile development can be measured as a form of bouncing. Both people and process can be affected by it. Just as when a reader will try a certain link and bounce back out before truly understanding the main points of the page, so time is a factor in allowing teams to come together properly.
Give your teams a chance to gel. Give them a chance to learn. Give them a chance to be successful and maybe the bounce rate will turn into a jump for joy.
Cockburn, A. (2006). Agile Software Development: The Cooperative Game. Upper Boston, MA: Pearson Education.
Ekas, L., & Will, S. (2013). Being Agile: Eleven Breakthrough Techniques to Keep You from “Waterfalling Backward”. Upper Saddle River, NJ: IBM Press.
Medinilla, A. (2012). Agile Management: Leadership in an Agile Environment. Heidelberg, Germany: Springer Science & Business Media.
Guest post by Johanna Rothman of Rothman Consulting Group
You have some agile teams who are successful. Good for you!
Now you have a strategic project that will require many agile teams to create a program. You know you need people in several locations. You know you need a cross-functional business team to make sure you address the needs of Marketing, Sales, and even Legal. How the heck can you make this happen?
In the agile project management literature, there is a notion of program management. A program is a collection of projects with one business objective. Each project might have its own deliverables. But the real value is in the program. The sum of all the projects is greater than any of the parts.
How do you scale from an agile project to an agile program without a lot of hierarchy?What is the Most Efficient Network in Your Organization Right Now?
When I talk to people about scaling agile, I ask this question:
If you want to move information in your organization fast, what do you?
What is the most efficient way to move information in your organization? People often smile and answer, “The rumor mill.”
People in your company have informal networks. They talk to each other. They help each other. They connect to each other in any number of ways which managers don’t know about. You can use these connections to help agile programs succeed.
“When I discovered that one of the testers needed a little help building an automated test framework, I took 15 minutes and did a screen-share. I showed her how I had started our framework for our testers. It wasn’t exactly what she needed, but it was a start for her.
She understood where I was going. She took that framework, improved on it for her team, and got them going on their own framework. It took me 15 minutes. That’s all. Now, they have their own framework, which is different from ours. That’s okay. Our testers got a show-and-tell the other day from their testers. Our testers came back all excited about the refactoring they could do. I knew it would pay off. – Senior developer
This anecdote is an example of small-world networks and communities of practice in action.
In large organizations, people have mailing lists that are the start of communities of practice. In this example, a senior developer answered a question for a tester. He spent a small amount of time coaching someone in another area of the program. The return was tremendous. “His” testers are now improving on their testing.
In small-world networks, people want to work toward a common goal. Many of them share connections, but it’s not necessary that everyone connect to everyone else. If enough people have connections to many other people, that is good enough.
In large organizations, between the project mailing lists, the functional group mailing lists, the project and program blogs and wikis, and whatever else the agile program uses for communication, there is often a way for people to connect with one another.
The small-world network helps people solve problems rapidly. But that doesn’t help people learn what the status is. How can you organize to learn the status in an agile program and elevate risks? Even if the technical folks can solve their technical problems, you still need a way to organize to see the big picture.How You Organize the Technical Teams in an Agile Program
The software program manager coordinates the delegate project/program managers of the feature teams. As you can see, some of those teams are small programs themselves.
Sally is an agile program manager for six feature teams. Her teams all collaborate on a significant feature set. They work together on a backlog. Once the product owner decides that the team has done enough for that backlog, the feature teams might work on other features. They might exit the program entirely. It all depends on what the program needs. In an agile program, you want to take advantage of your ability to replan based on feature team availability, and backlogs being “done enough.”
Joe, Tim and Henry have single-team projects. In order to show status and elevate risks, Joe, Tim, Henry and Sally would come to the program team meeting, along with the program product owner, the deployment person, and anyone else you need from the technical side of the program.
If you have a program architect, that person would participate, also. Teams embed architects in an agile program. However, you might need to discuss the risks at the program level with an architect. It all depends on your risks and challenges.
A program team meeting is a problem-solving meeting, not a micro-commitment meeting. Since the technical people can solve problems, you don’t need a daily standup for the program team. You do need to elevate risks, and see product backlog burnup charts, among other metrics, to see if the program is on track from the technical perspective.
That’s just for the technical team. What about cross-functional business interests? Cue the Core Team.Agile Program Management Works Across the Business
Back in the ‘80s, I facilitated a cross-functional Core Team across the business. We had a person each from Sales, Legal, Marketing, Training, Finance, Marketing Communications and Hardware. We needed to release within a particular market window so we didn’t miss a specific opportunity. I bet this sounds familiar to many of you. We had inter-dependencies up the wazoo.
I didn’t know about agile. I didn’t know about Kanban. I knew about the value of monthly deliverables, and asking people to commit to small, do-able actions. I knew they each had their “own” work to do. I knew that the program’s work was their work, too. But I suspected they wouldn’t see it that way.
At the beginning of the program, eight months before our projected launch, I asked them to meet biweekly for an hour. We had an action-item list at the bottom of our agenda, which you would recognize now as a Kanban board. Everyone had just one item, and the item only took a few hours to accomplish.
By the six-month mark, we met weekly. By now, we understood how to work together across the organization. The Hardware guy understood how to work with the Marketing guy. (These guys are all generic guys. Some of these “guys” were women guys.) The legal guy was happy because we were not going to ship an empty box. So was I!
Best of all, the product came together, as planned. Not as estimated—not even close. But because we worked our inter-dependencies each week, and replanned as we saw our deliverables, and kept our action items small, we were able to release the product in our market window.
We worked in a cadence, kept our WIP (work in progress) limits small. We replanned. We used what we now know as Lean and agile approaches.Agile Program Management Scales Out, Not Up
Note that the teams don’t try to solve everyone’s problems. The technical teams solve the technical problems. They integrate all the time. They provide good data and insight to the technical program team.
The technical program team solves the risks and understands where the program-level problems are. The program team doesn’t have to solve the technical problems, unless the technical teams are stuck. The technical teams can always ask for help.
Because agile program management uses small-world networks, and is not a hierarchy, this approach scales out well.
The core team solves the cross-business problems. They do not attempt to manage the project portfolio, unless that problem is also in its purview. In small companies, it might also manage the project portfolio.
Program management is not new. Applying agile and Lean methodologies to program management is a new twist on program management.
To read more, see Agile and Lean Program Management: Collaborating Across the Organization, https://leanpub.com/agileprogrammanagement.About Johanna Rothman
Johanna Rothman, known as the “Pragmatic Manager,” provides frank advice for your tough problems. She has been in the software industry for over 35 years—and she never fell for the waterfall promise. She’s the author of eight books about management and project management. Her most recent book is Manage Your Job Search. Her upcoming book is Agile and Lean Program Management: Collaborating Across the Organization. Read more of her writing on www.jrothman.com and www.createadaptablelife.com.
I see Craftsmanship as the answer to an issue that has been rising in importance over the past several years. Agile, as a development methodology, has hit the mainstream. While in many ways this is a good thing, there are some drawbacks. The majority of attendees at the major conferences are now project managers, while in the past they were developers, or at least a fair mix of both. This has helped socialize the ideas around agile development and is a good thing, but we also need to seek balance in the Force. This has given rise to the Software Craftsmanship movement, which is focused on the Art of Writing Software, and what is required to create great software, especially in the agile world. In a previous post, I mentioned how important Craftsmen are to the agile world. But how does one become a Craftsman?
First, lets take a look at the state of affairs of our industry, job-wise. It is pretty well known that being a software
developer is a lucrative career, but the numbers are still somewhat surprising. According to the U.S. Bureau of Labor Statistics, the median salary for software developers in the United States is around $93,000. The statistics further show that the number of jobs in the software development field will grow by 22% in the next 10 years. This is significantly higher than the rest of the job market. So how are we going to fulfill these needs with high-quality developers?
Obviously, we need to train a lot of really talented people. We need them to be able to create software well, and also to be able to work well together. Currently, the primary source of education in software development is via the universities and colleges. Unfortunately, not only is this failing to provide enough programmers for the jobs, it is also failing to provide the high level of quality and experience we will need.
Now, universities are great for a lot of things. They provide a strong level of theory and understanding of the underlying science and logic. What they don’t provide is real-world experience and practical applications of knowledge. This needs to come from somewhere else. My suggestion is to turn the clock back a few hundred years, and turn your team room into a workshop. Let’s populate that workshop with Craftsmen. We may not have all of the Craftsmen we need to begin with, so we need to build and grow them. This can be done by applying an apprenticeship program and using the craftsmen’s model for further career development. Let’s take a look at how this would work.
Let’s begin with the idea of hiring apprentices. An apprentice is someone who may or may not have a formal education in software development. What she will have is the desire to learn. The question remains, “What will she learn and how will she learn it?” For starters, we will focus on five main areas:
- Crafting Code – The art of using one or more programming languages to create clear, well-factored code. We want our apprentices to be polyglots by the time they become journeymen, so we will do this in more than one language.
- Applied Principles – Well-written code isn’t enough. An apprentice needs to understand principles like SOLID, and know how to apply them.
- Technologies and Tools – While programmers need to be able to practice activities like Refactoring by hand, they also need to know how to use certain tools, as well as which tool to choose for a particular task.
- Work Habits – Programming is about more than just showing up, slinging some code, and going home to play Mine-Craft. Especially in an agile software development shop, we need to be able to build muscle memory around the activities that make good programmers great, such as TDD, Continuous Integration, etc.
- Soft Skills – The days of the socially inept programmer are over. Software apprentices will learn how to work in a team, how to communicate with others, and other soft skills that tend to be forgotten in the traditional learning environment.
An apprentice will learn these foundational areas through working on real projects, under the tutelage of a mentor. Ideally, that mentor might be a Master Craftsman, but if one isn’t available, then experienced, well-versed Journeymen will make good mentors as well. At the beginning of her apprenticeship, the apprentice might do some basic things like creating and maintaining the continuous integration environment, some bug fixing, or other tasks. Over time, she will work with her mentor and other Craftsmen on real-world activities and projects, continually adding value to the team. When the apprentice has demonstrated her ability to move on to bigger and more challenging projects and tasks, it’s time for her to be recognized as a Journeyman. We will explore more about the life of a Journeyman in another article. In order to become a Journeyman, the apprentice must show her expertise by doing, not by taking tests. Real work pieces that evidence her abilities in various areas and languages, coupled with having paired with everyone on the team, will determine an apprentice’s ability to move on.
Guest post by Mike Cottmeyer of LeadingAgile
When you get right down to it, a Scrum team is fundamentally a container designed to encapsulate the entire product delivery value stream into a single workgroup.
The value stream associated with software development typically goes something like this: analysis, design, build, test, and deploy. That’s pretty much everything you need to develop a working, tested increment of the product… and is, therefore, what defines the basic requirements for a Scrum team.
When you put analysts, designers, developers, and testers into a single workgroup; let them work across skill-set boundaries, self-organize to balance load; and have them collectively produce a working, tested increment of product on regular intervals, you can reduce a tremendous amount of planning complexity.
Your organization has to get past the belief that individual productivity and utilization are the measures of effectiveness. You have to focus more on team throughput and flow of value, but the construct allows you to move fast, change direction, and adapt as we learn more about the emerging product. Planning is simple, objectives are clear, and outcomes are measurable.
Why Scrum Breaks?
The problem with many Scrum implementations is that the team doesn’t actually encapsulate the entire value stream. In almost every real-life organization, someone who is necessary for the team to complete their work doesn’t actually live in the Scrum team. This is very simply what causes Scrum to break. Dependencies kill Scrum.
When this happens, we get into an agile project management mindset. We are running some of the work through the Scrum team, but we need extra coordination mechanisms to help us line up the Scrum team with the other parts of the value stream that live outside the team. We have external planning dependencies that have to be dealt with.
It’s my assertion that these planning dependencies are what result in teams going through the motions of Scrum without realizing value Scrum promises. Last month I did a talk at Agile 2014 that was all about why agile fails in large enterprises. The whole talk is about how to systematically break dependencies between teams.
That said, some organizations are simple enough that a Scrum of Scrums is sufficient to model and deal with the unavoidable coordination issues. Some organizations have to be more proactive coordinating complex backlogs and use constructs like Product Owner Teams, Solutions Teams, and Requirements Clearinghouses.
The key takeaway here is that when you have a Scrum team where the entire value stream is not encapsulated, you need something outside the basic Scrum construct to coordinate across the teams. Pick your poison, but something outside the team almost always has to be present.
SAFe (Scaled Agile Framework) and Value Streams
I want to see if we can pull this up a level and talk a bit about SAFe. Coming off the Agile 2014 conference in Orlando, SAFe was everywhere… and for good reason. Everyone is trying to figure out how to take the concepts we’ve learned with Scrum and get the value at enterprise-level scale. Scaling Scrum is the topic du jour.
Honestly, I don’t keep up with SAFe in detail… I’ve never been in SAFe training… and I’m definitely not part of the inner circle of SAFe thought leaders. That said, I’ve read everything Dean (Leffingwell) has written since he released Scaling Software Agility, I have a ton of respect for his work, and I agree with the basic patterns he has introduced.
(At) this conference though, I heard something I hadn’t really heard before. It seemed that everyone was talking about value streams relative to SAFe. I’m sure the concept has been in SAFe for a while, but it caught my attention differently this time around. It made me wonder if I should think about SAFe similarly to how I think about Scrum.
At LeadingAgile, we typically coach an explicit value stream in the middle-level program tier. We think about progressive elaboration and maximizing the flow of value in the middle tier. We usually encourage an explicit Kanban flow that respects some of the upstream and downstream work processes we see most often in product delivery organizations.
It occurred to me that SAFe isn’t modeling the value stream explicitly in the middle tier; it is managing the work through the PSI/PI planning meeting, fundamentally encapsulating the entire value stream within the planning construct. In short, SAFe is fundamentally operating like a big Scrum, just encapsulating a larger value stream.
Whereas I’ve been thinking most about breaking dependencies, SAFe appears content with managing dependencies and making them visible and explicit in the planning session. This is absolutely a necessary step in the process, but by not dealing with the root cause of dependencies directly, I believe they will limit your ultimate agility over time.
SAFe will struggle with dependencies at scale for the same basic reason Scrum struggles the team level. Dependencies make it hard to move.
We’ve been giving a lot of thought lately to breaking dependencies, and our work with clients is fundamentally about forming complete cross-functional agile teams and systematically breaking dependencies between them over time. We believe that this is the only true way to scale agile indefinitely to the enterprise.
We believe this concept is methodology-independent and will make any methodology you choose better in the long run.
Why SAFe Breaks?
Scrum isn’t trying to break dependencies within the team; it is merely trying to encapsulate the value stream, allowing the team members to work across role boundaries, self-organize around the work and stabilize throughput, while holding them to producing a working, tested increment every couple of weeks.
SAFe isn’t trying to break dependencies within these larger value streams, either. It is merely trying to encapsulate the value stream similarly to Scrum, allowing team members to work across role boundaries, self-organize around the work, and stabilize throughput while producing a working, tested increment every PI.
There are clearly more constructs within SAFe than exist within Scrum to deal with the larger effective team size and integration tasks, but I think that the pattern fundamentally holds. I never really thought about it that way before. I’m curious if anyone else has ever thought SAFe as kind of a big Scrum?
If we know that Scrum implementations struggle when the entire value stream can’t be encapsulated within a team of 6-8 people, do SAFe implementations struggle when the value stream can’t be contained within a team of 125? If my assumption about dependencies and value streams holds, I suspect they would.
If SAFe is ultimately going to struggle at scale beyond 125 people, does that mean that we are going to need the same constructs for coordinating value across teams that we need in Scrum? At some point will we find ourselves talking about ‘SAFes of SAFes’ or ‘SAFe Product Owner Teams’ or ‘SAFe Portfolio Solutions Teams?’
I suspect we might. I think we might also see evidence of this already.
Maybe there is some stuff in SAFe that already accommodates this, but I’m curious what’s out there to tactically coordinate across SAFe value streams? Remember, I’m not talking about investment decisions across a SAFe Portfolio… I’m talking about managing dependencies between value streams. I gotta figure some folks are dealing with this already, given how well SAFe is doing in the market.
If anyone has any insight or can point me in the right direction, I’d appreciate it. I’m interested to know how the insiders think about this? Is anyone inventing things outside the SAFe body of knowledge that are being written about? Where is the body of knowledge emerging outside of the official cannon, and are people talking about this?
Ken and Jeff Got it Right
Back in 2006 Ken Schwaber put up a slide where he illustrated a team-of-teams structure, one where lower-level Scrum teams were encapsulated in a higher-order Scrum of Scrum construct. Back in 2006 I was thinking that there was no way this would work in the absence of very loosely coupled teams (and at that time, that was NOT my reality).
A few years ago, I heard Jeff Sutherland and Jim Coplien give a talk at the Scrum Gathering in Orlando. The one line I vividly remember from that talk was that, “teams were never expected to self-organize across class boundaries.” They were implicitly saying that encapsulation was the expectation for a Scrum team to form.
Jeff Sutherland, as we speak over at Scruminc.com is talking about Object Oriented Design (OOD) in Scaled Scrum implementations. He is basically making the case that Scrum teams are intended to be formed around Objects in an organization. It is a prerequisite for Scrum to work.
I think that this one concept is a point which has been wholly misunderstood and largely ignored by organizations adopting Scrum. Many people implementing Scrum nowadays don’t have any idea about OOD principles, let alone as they relate to organizational design and team structure.
When you read Craig Larman and Bas Vodde’s stuff around LeSS (Large Scale Scrum) and consider the structures they’ve put into place, you have to view those structures through the lens of an Object based organizational structure. Their work is built on the same foundation that Ken and Jeff laid 25 years ago, but that is seldom implemented.
I find myself fundamentally in alignment with Ken, Jeff, Bas, and Craig… and I think theirs is the best end-state for a scaled agile enterprise. The problem is that their underlying operational structure for a scaled Scrum implementation to work… the Object Oriented Enterprise… doesn’t exist in most companies adopting Scrum.
SAFe is a Compromise
I think I’m coming to the conclusion that SAFe is a reasonable compromise given the operational constraints in many organizations. If you aren’t going to form teams around Objects in your organization, you probably shouldn’t bother implementing any of the Scaled Scrum variants. You’ll just get frustrated.
That said, I do believe that SAFe is going to suffer from many of the same problems that Scrum deals with organizationally in the presence of incomplete or dependent value streams and a lack of organizational object orientation. It’s just a matter of time and scale.
At this point in the evolution of my thinking, I find myself in a place where I don’t believe the scaled Scrum stuff will work in most companies in their current state. I think SAFe will work to a point, but if it’s sold as the final destination, we are going to limit our ability to scale and ultimately limit our ability to be agile.
We can only be as agile as the size of the team, and the independence of the value streams, and the length of the PI boundary. I think organizations will soon find they are going through the motions of SAFe without really solving the problem. Again, it sounds just like where we are with Scrum in most companies.
Refactoring Your Enterprise
The only real, long-term sustainable approach to Scaled Enterprise Agile is to take the long, hard road toward refactoring your enterprise into an organization based around the OOD principles that were implied, but maybe not explicit, when agile was formally articulated 13 years ago. The problem is that this message doesn’t fill CSM classes and has to be sold all the way at the top of the organization. It will require a significant investment on the part of the executives.
The cool thing is that in the presence of this kind of organization, everything else starts to make sense. You can see a place where Scrum and Kanban live side-by-side in peaceful harmony. You can see where the technical practices fit in at scale. SAFe, Disciplined Agile Delivery (DAD), and LeSS all have a place in the pantheon of ideas. No matter which path you take, the Object Oriented enterprise makes everything else make sense. It’s the right context.
With the Object Based Enterprise as a sort of backdrop to sort out all the different perspectives on agile, we can begin to see that the conversation around potential future state starts to get WAY less interesting than what it takes to get there. I think the interesting conversation is around how we do the refactoring in the first place, and what the possible transition patterns look like which help us get there, while still running our businesses effectively.
If I think about it… that was really what my talk last week was about. It’s up on my blog, and was recorded by the conference, but that might take some time to publish. I think I’ll do my next post as an overview of the content and rationale behind the material in my presentation. Let me see if I can make that happen this weekend
Guest post by Venkatesh Krishnamurthy, Advisor and Curator, Cutter, Techwell, Zephyr
Some time back I noticed something odd with an agile team. Team temperature used to be 10 out of 10, and each team member expressed their happiness working on this project. I was curious to find the secret behind an “always happy team.” A bit of interaction with the team and the ScrumMaster revealed some disturbing secrets. Here are the key ones:
- The team is self-organizing, and individuals can pick the story of their choice and deliver at their discretion!!
- Team has neither time pressure nor delivery timelines
I thought to myself that this is not a self-organizing team, but a directionless team.
As Esther Derby points out, there are several myths and misconceptions about Self-Organizing teams. I did cover a bit about these myths during my talk at Lean Agile Systems Thinking conference(LAST) in Melbourne, which is available on Youtube (toward the end at 1:03 minutes).
I understand it is not easy to build a self-organizing team, but there are principles enabling leaders in building such agile teams.
One of the best analogies that I have heard so far about self-organizing teams is from Joseph Pelrine. As Joseph puts it, building self-organizing teams is like preparing soup. I thought it would be easier for readers to understand the self-organizing concept if I map the soup preparation steps to the self-organizing steps. Yes, soup preparation involves many more steps, but the key ones below would give the clues to readers for further analysis.
The below table illustrates the mapping:
- A self-organizing team needs a leader, the right amount of pressure apart from the right set of constraints/goals to succeed.
- The true test of the self-organizing team is their collaboration ability during war time and not during peace time.
- There is a difference between a team organizing themselves and a self-organizing team. Don’t ignore the “self” part.
The first four Principles of Capacity Planning start us on a planning journey to run a business more effectively. Here are the topics we’ve covered so far:
- The Team as the Resource Unit
- Getting forecasting efforts Roughly Right
- Matching Supply to Demand
- Using a Continuous Planning Cadence
This post addresses the value of tolerating incomplete data in portfolio planning -- a principle that applies to both demand and supply. Here are some specific examples for each.Demand Tolerance: Detail Initiatives Only As You Get Close to Scheduling Them
When we plan out 12 to 18 months, we’ll make decisions on less-accurate data than we’ll have for, say, the upcoming quarter. In other words, we’ll be less certain as our planning horizon moves farther into the future.
Experts and highly competent professionals strive for perfection. Big planning mistakes have ruined careers. Yet to be successful, leaders must make decisions using imperfect information. Strategic planners have to navigate uncertainty and risk as investment scenarios become plans of record. To have a reasonable chance of success, we must know something about the investments we select to execute on: the rest of the information is either knowable or unknowable. There is a huge cost associated with gathering this knowledge. On the other hand, tolerating incomplete data is no excuse for ignorance.
A prominent, former presidential cabinet member advised that you not take action if you have only enough information to give you less than a 40 percent chance of being right; but that you shouldn't wait until you have enough facts to be 100 percent sure, either, because by then it’s almost always too late. This instinct is right: excessive delays in the name of information-gathering leads to analysis paralysis. Procrastination in the name of reducing risk actually increases risk. For example: one Fortune 500 organization was spending so much time to have 100 percent of the decision-making information that its approval process took years -- longer than the time required to implement the approved projects and programs.
When applied to an annual cadence, expect to be on the low end of this information-gathering range (around 40 percent.) At this point you’re planning at more of the initiative level, maybe with some features identified. With roughly right estimates, we will set ourselves up for more accurate near term plans. Within a quarter, I expect to be closer to 70% because I should have more complete information. As you embark on continuous planning cadence, the ability to manage uncertainty becomes much more tolerable because you know you will have the opportunity to inspect and adapt at more frequent intervals. In today’s fast-paced world, the cost of delay can be so high you have no choice but to get comfortable with operating on good-enough data.
One of the proven benefits of Agile software development methods is that you can adapt to necessary changes in schedule and priorities, and avoid the misalignment of scheduling work far ahead of execution. In a continuous planning cadence, annual planning becomes part of long range business commitments, forecasting and budgeting, while scheduling becomes part of rolling wave prioritization and value delivery.
Ironically, traditional sources of guidance support the notion of tolerating incomplete data. According to PMBOK, “A Planning Package is a work breakdown structure component below the control account with known work content but without detailed schedule activities.” Each organization should determine its policies for when it’s feasible to refine details and schedule them. Our experience shows that this planning horizon for prioritization and value delivery in today’s fast-paced world is about one quarter (three months.) With these rhythms, we can get better at operating on “good enough” data.Supply Tolerance: Fuss Only When You Must
When working with large customers, we’ve found that most managers have been burned by failing to pay attention to the scarce capacity of specialization areas. Examples include UX designers and DBAs, as well as expertise specific to a company technology environment, such as network or security engineers. The cost of not accounting for this scarcity of talent is an overly optimistic plan that does not match the reality of what can be delivered. This is one criticism of Agile methods to-date: they lack a good approach for handling exceptions to cross-functional teams.
The key to tolerating incomplete data is to plan at the delivery group level and, if necessary, the delivery team level. This respects the principle of the team as the resource unit and has the added advantage of simplifying the capacity planning exercise by a factor of 10 (roughly assuming 10 individuals per team.) Only when planning at the team level isn’t roughly right do we fuss more, usually because of the need to pay special attention to scarce expertise. Because managing expertise adds overhead to matching supply to demand, the goal is to fuss only where you must!
How do we fuss just enough? Let's take the example of a fictitious company that has both retail brick and mortar stores and a successful online presence. Initially, this organization had a platform delivery group that provides all the backend services. Every other delivery group was dependent on the platform group. With so many dependencies, managers were constantly scrambling to remove bottlenecks and resolve schedule conflicts. The solution was to distribute the platform delivery group onto several of the other delivery groups so they could be made “whole” (each group had what is needed to deliver value with minimal external dependencies.) By designating “platform” as an expertise, and just a little extra fussing to account for platform constraints, we can match supply and demand and have better results.Roles and Expertise
Expertise can be used to support flexible resourcing. Take, for example, an organization that has several delivery groups, with some aligned to specific products. Most of the time, each delivery group is self-sufficient in delivering their allocated work. When there’s an unusually high need for a given expertise, the delivery group can be augmented by providing additional capacity from other delivery groups for that expertise. One customer told us, “We rob teams from Peter to pay Paul all the time in order to deliver maximum value.” Expertise should only be fussed with when we must.
What about roles? Modern capacity planning strives to use role as an attribute of a team. Applying roles to teams helps identify team competencies and provide convenient capacity planning building blocks. A team’s role can be thought of as expertise. Although we value teams over individuals, we recognize that individuals are the basis of great teams (it’s commonly cited that a good programmer can outperform a mediocre one by a factor of 10.) When the team is the fundamental planning currency, the need to fuss about the roles of individuals diminishes. Thus, resist the urge to track capacity of individual roles within each team. For planning purposes, this would be artificially precise (read more about the capacity planning principle of “roughly right.”)
This blog rounds out the five principles of modern capacity planning that should help you have a less dreadful annual planning season. If you'd rather listen to an overview of these principles, check out the "Business Agility and Annual Planning: Solving the Paradox" webinar.
Most importantly, don’t waste any more time creating precisely wrong plans when you can leverage Rally’s expertise in portfolio capacity planning.Brent Barton
Program planners in IT organizations have a dilemma: On one hand, their agile teams tell them that if requirements are defined up front, agile teams cannot operate; but on the other hand, the program’s budget and scope need to be defined so that resources can be allocated and contracts can be written for the work. How does one reconcile these conflicting demands?
With the large number of organizations now adopting agile methods, the existing body of literature has paid significant attention to the function of project management, business analysis, and more recently program management. This is understandable as individuals filling these roles are ubiquitous and critical to the operation of their respective organizations.
Many organizations have an additional formalized function, project portfolio management (PPM), that is also critical to the organization but gets little attention — especially in light of the considerable desire being shown to scaling agile to the enterprise level. The focus, objectives, and responsibilities of agile PPM must fundamentally shift when transitioning to an agile model, structure, and culture. The reason for this is simple—the same agile principles that are being applied to individual projects can also be leveraged to manage the portfolio.
Below are two ways that agile PPM differs from traditional PPM:
Traditional PPM: Optimize portfolio resources (individuals) by skill set
Agile PPM: Maximize value delivery to customers by team capability
Traditional projects, while still delivered by teams, are much more focused on optimizing skill set across a portfolio. One reason for this is because most traditional organizations are structured and organized by functional specialty. That is, the organization’s structure is very hierarchical and often has individuals within a particular functional specialty (business analysis, quality assurance, project management, etc.) reporting to the same manager.
Another reason is that projects move through the process by passing through one of several phase gates such as requirements, design, test, etc. When this is the case, project execution may be throttled by a particular skill set at each gate. For example, if you have five business analysts, you will be limited to the number of projects that can be active. However, most organizations ignore this fact and still have far too many projects active at any time; this only adds needless risk. The sad truth is that most organizations really have no idea of their true project capacity.
In agile organizations, the team (not the individual) is the unit of capacity measure. Therefore, if you have three teams that are capable of delivering an initiative or feature, you are limited by the number of teams. So, how many projects of each type can you have active at any one time? I don’t know; each situation will vary by organization, team, and context. However, to get started, try setting the limit to be equal to the number of teams with the capability of delivering that type of solution. If it doesn’t help, experiment.
For example, if you have five products that need mobile solutions, but only have three teams capable of doing the work, only start the three that will deliver the highest customer value. Of course, that assumes that the teams are not already working on other items.
Traditional PPM: Maximize Revenue and Evaluate Project Health
Agile PPM: Govern Empirically through Validated Learning
One of the primary goals of traditional PPM is maximizing revenue… that is, how much money a particular project or product can add to the “bottom line” of a company’s balance sheet. In today’s economy that is characterized by pervasive, disruptive technology and consumers that demand choice and flexibility focusing on revenue alone misses the point.
Revenue is the metric of wildly satisfied customers.
Stated another way, many would say that the sole objective of PPM is to maximize shareholder value. This is done through increasing revenue, but it misses the point. Because customers have flexibility and plentiful choices, the focus must be on maximizing customer value. By focusing on customer value, if shareholder value doesn’t increase, it may be because you’re building the wrong thing. Wouldn’t it be appealing to find that out sooner rather than later?
Further, traditional PPM typically measures the health of the agile portfolio by evaluating the health of its component projects. This is great—in theory. But one of the big problems with this approach is the way in which health is typically measured. It’s most commonly done through subjective mechanisms like project status reports, achieved milestones, and progress stoplight indicators. None of these approaches offer an objective mechanism of determining if the project is actually building the right thing. Personally, I’ve managed projects that have delivered the wrong solution on time and within budget. The kind of objectivity that’s required is customer validation.
A more agile PPM approach would be to introduce some mechanism of validated learning to help us make more sound and responsible decisions for our customers about what projects or products to continue funding. Validated learning is a key aspect of the Lean Startup approach made popular by Eric Ries’ book of the same name. Agile projects aim to build small increments of a product. This means we are dealing with smaller return-on-investment (ROI) horizons.
Through agile PPM it’s possible to incrementally fund two projects to experiment with two different solutions to a (perceived) customer problem. This is known as A/B testing, a.k.a., “split testing.” Because agile methods allow us to get solutions into the hands of customers more quickly, we can evaluate the results of our experiments and shift funding to investments that are more promising and pertinent. Because the funding is done incrementally, we need not fund an entire project for an extended period before finding out whether our assumptions were incorrect.
While these are only two of many considerations when adopting agile PPM, each has the potential to make an immediate and lasting impact on your organization and its customers, thereby, positively impacting your shareholders as well. In my opinion, the sooner organizations can sow the seeds of customer satisfaction through validated learning, engagement, and collaboration, the sooner they will reap the rewards of increased shareholder value.
What are your thoughts? How can you begin to apply these concepts within your own unique context?
This sounds a little like Cognitive Behavioural Therapy where unhelpful thoughts (ANTs) are challenged and replaced with more positive alternate views (APEs). CBT seeks to uncover and disempower negative core beliefs that generate negative thinking habits. These harmful thoughts can lead to defensive or reassurance seeking behaviour that limit the person. By providing more realistic core beliefs one can transform a downward spiral of negative thinking into an upward soaring of self actualisation.
Good luck and thanks.
-by Duncan Green on 12/12/2011 at 12:59 PM
thank you, Duncan, I’ll have to look into that … for me, I am not replacing any views with any other views, I’m just cleaning the picnic cloth of my mind from ants (really) :). so I’ll have to peek at CBT next. cheers, Alistair.
-by Alistair on 12/13/2011 at 10:25 PM
Dr., I an intrigued by the ease at which you transcend between humanity and software enginrering as an integrated science. Humans create software and in this example I enjoyed the way you programmed your mind with what the other gentleman referred to as cognitive behavioral therapy.
Your APE mind program approach highlights humanity’s next feat the application of software engineering to the human mind.
Anthropology in software engineering is a very fascinating topic.
-by Pablo Beck on 8/16/2014 at 11:41 AM
Hi, Pablo, thank you, that is very kind. Indeed, in 1996 I gave a small panel position statement What can OO programming learn from anthropology? (discussion: Re: What can OO programming learn from anthropology?); and later hired an ethnographer to follow me around on a job to watch everybody. In 1997 I did another little panel thing with Software design and anthropology. So, in short, yes, I think software people can learn a lot by partnering up with anthropologists. ... The little thing with ANTs and APEs is just trying to sleep better at night : ). Alistair.
-by Alistair on 8/16/2014 at 1:55 PM
Trying once and yet again to describe the relationship of use cases and agile development, I found myself using carpaccio as a reference.
Carpaccio is beef sliced so thinly you can almost see through it.
Agile developers apply micro-, even nano-incremental development in their work. By this I mean that they take on a request for incremental end-user-visible functionality that takes anywhere from 15 minutes to a few hours or a day to implement. In developing this web site, it typically took us 15-30 minutes to implement each new piece of functionality.
That’s not because we’re so fast we can development 100 times as fast as other people, but rather, we have trained ourselves to ask for end-user-visible functionality 100 times smaller than most other people.
This is carpaccio of the functionality.
User stories describe these this thin slices very well.
The process runs in reverse of the culinary carpaccio. In culinary carpaccio, we start with an animal (OK, you vegetarians might be making zuccini carpaccio), slice it into bits and serve it. In programming, we start with an idea of an animal, describe it, and have the programmers produce it in reality.
Suppose now that someone has in mind an elephant.
They start with the tail, mentally slicing off and describing behavior-carpaccio for the programmers to implement. We are about to face two questions:
- What will happen to the morale of the group when they finish the tail and suddenly hit the body?
- How do we ensure that what comes out the production process is really an elephant (or whatever animal the sponsor had in mind)?
Life seemed so easy for a while – the slices were thin and easy to produce. Then one day the size, shape, texture, suddenly changed. Everything got more difficult. Working on elephant-body-sized carpaccio slices is much more daunting. Velocity goes down, morale goes down, etc.
The envisioned product always had a size and a shape. User stories don’t convey either. Therefore, use something else to convey them. Jeff Patton uses “story mapping” to convey that, but that is the only other thing I know of that comes close to doing the job beside use cases.Produce an elephant
What will assure that an elephant will come out the other end?
In XP, the “customer” is declared to be omniscient.
Ask the customer anything and he or she will answer with an answer that is carpaccio thin and guaranteed to fit the rest of the carpaccio slices to produce an accurate elephant.
However, very few real people have that capability. We need something else.
Use cases have a shape and a size – they describe the size and shape of the elephant, so that each carpaccio slice can be set at its correct place in the elephant. The use case gives the programmers context, so they can ensure the piece fits its adjacent pieces, and the testers can check that it does.
Use cases don’t slice very well into carpaccio – user stories do that.
Moral: learn to write 1-2-page use cases to describe the size and shape of the elephant, so you can slice it into carpaccio for development; learn to write micro- user stories from the use cases so your agile developers can work in micro-increments.