What’s So Special About Agile?

SpecialButtonAdmit it.  You enjoy telling people that you’re an Agile “practitioner”, “coach”, or “evangelist”.

It’s OK – I do too.

I also enjoy reading a well-researched article in, say, the Harvard Business Review or the Wall Street Journal that validates what we do every day in the Lean-Agile community.  It shows that they want what we got (and sometimes, vice versa).

But I recently happened across the April 2011 issue of Real Simple magazine, the riveting theme of which was “Spring Cleaning”.  My curiosity as to how that subject could possibly warrant an entire issue led me to thumb through the pages until I came across an article entitled “This is Your Brain on Procrastination”, written by Amy Spencer.

The article presented the following list of things to do in order to get important things done around the house:

  • Do the worst thing first (you won’t have the energy to do it later)
  • Start your day over at 2:00 PM (assess and adjust regularly)
  • Make the job smaller (and do it just “good enough”)
  • Create an audience (make yourself accountable)
  • Race the clock (see how working in short, timed bursts affects your productivity)
  • Don’t interrupt yourself (or let anyone else do so)
  • Plan an unprocrastination day (prioritize and then immediately DO)

Sound familiar?  I thought so, too.

Yes, three years ago, guidance for which people still pay good money to be Agile-certified was published in an article on getting ahead on household To-Dos.  That tells me that maybe Agile isn’t so special anymore.

I think that’s actually a good thing.

Why? Because I noticed a long time ago that most of us tend to use one system of thinking at home, and another when we’re at work.  It’s almost as if we swap brains somewhere between the front door and the driveway.

For example, Home Brain says, “I have only so much money and so much time, so I’m going to have to accept the fact that I can’t have both a new refrigerator AND a new fence.”

Work Brain says, “Based on our best information, I know we can only really do the fridge. Tell you what: I’ll throw the fence in as a ‘stretch goal’.”  (Home Brain’s too smart for that.  He knows what stretch goals turn into.)

My efforts over the last several years, to a great extent, have been focused on simply getting people to take their Home Brains to work with them.  The addition, now, of even informal Agile thinking to Home Brain’s innate clarity and common sense will make it that much more valuable at work.

So what if Agile’s mysteries are being divulged to the uninitiated as they stand in the supermarket checkout line?   If value-oriented and throughput-focused thinking can permeate such mundane areas of our lives as decluttering a closet, then the the way we are trying to shape how we think at work will become more similar to how we think at home.

That should make bringing an Agile mindset into the workplace more natural.  I’m OK with that, even if it means Agile loses some of its status in the process.

Posted in Agile Adoption, Agile Management | 1 Comment

Is Your Sprint Pipeline Running Well?

Most agile teams, when starting out new on their agile transformation road, conduct all sprint related activities in the same timebox, i.e., sprint planning, sprint execution, sprint review and sprint retrospective.  This is illustrated in Figure 1, where each sprint (from Sprint 0 through N+1, represented by each row) is mapped onto a single sprint timebox (Timebox 0 through N+1, represented by each column), and successive sprints are executed in successive timeboxes in a sequential order (Sprint 0 in Timebox 0, Sprint 1 in Timebox 1, and so on).

Figure1

 Figure 1: Sequential execution of sprints

For example, all implementation tasks for Sprint 2 (analysis, design, code development and unit testing, acceptance test case development and acceptance testing, defect fixing – done concurrently (not as a mini-waterfall) by a self-organized, cross-functional team — are completed in Timebox 2.  Sprint 2 planning is completed (before Sprint 2 starts) in approximately 4 hours for a two-week sprint (or 8 hours for a four-week sprint); and sprint review and retrospectives are completed in approximately 1 hour each for a two-week sprint (or about 2 hours each for a four-week sprint).

Each light pink vertical thin box separator between two successive sprint timeboxes represents a small timebox to complete all these ceremonies, i.e., sprint review and retrospective for the previous sprint as well as sprint planning for the next sprint.   Thus all these tasks for successive sprints are carried out in a sequence of successive timeboxes.  This is a simple and straightforward model where work goes in each timebox sequentially, sprint by sprint, without any overlap.

What are the advantages of and the challenges for the simple model of sequential sprint execution shown in Figure 1?

Advantages of the sequential sprint execution model:

1AS.    Simple to teach, understand and learn – and hence covered by all agile text books, training courses, and certification programs.

2AS.    Conceptually simple to execute — but fraught with challenges as explained below.

Challenges for the sequential sprint execution model:

1CS.     Analysis issues may block the team and reduce throughput: Analysis of backlog items (or stories, as they are often called) must involve intense conversations among the product owner and team members, and confirmation of each story by defining its acceptance criteria.  Stories can be properly understood only through conversation and confirmation parts of the story metaphor of card, conversations, and confirmation.   The product owner should answer the questions and clarify the issues raised by the team members before design and code development work can start.     This goal – clarifying all stories to reach a collective, common, shared understanding – may become very challenging if all stories are analyzed during the same timebox in which they are scheduled for design, code development, testing, defect fixing and delivery.   This is so because the product owner may not know all the answers to team members’ questions without consulting users, customers and stakeholders, and performing necessary market and customer research and analysis.  This entire analysis effort is often difficult to compress in the same timebox when design-development-testing-defect fixing work is also going on concurrently because the actions of many actors responsible for providing answers to the analysis questions may be beyond the control of the product owner (for example, some stakeholders or customers may not be available to provide specific clarifications within the timebox time constraints).   The net effect of this challenge is often reduced team velocity (throughput) as the team is still waiting for stories to be clarified while sprint execution is going on, and team members may be even blocked waiting for clarification.  Finally the sprint timebox may be over before some planned stories could be completed by the team members and accepted by the product owner.

2CS.     Sprint planning may be less effective and efficient: Without clear and shared understanding of each story by all team members and the product owner, the team will find it difficult to estimate the work effort and complete all sprint planning tasks in the allocated time for sprint planning (approx. 4 hours for two-week sprints and 8 hours for four-week sprints).   Needless to say poorly planned sprints contribute to poor (ineffective and inefficient) sprint execution and reduced throughput.

A better model to overcome the challenges of the sequential sprint model is to execute sprints in a pipeline fashion as illustrated in Figure 2, where the Analysis task is performed one timebox ahead of the Design-Code-Test timebox for each sprint.  For example, development and analysis of Sprint 2 backlog is performed during Timebox 1 (one timebox ahead of Timebox 2), while the actual design, code development and unit testing, acceptance test cases development and testing, regression testing and defect fixing tasks for Sprint 2 are performed in Timebox 2.  This same pattern repeats for each sprint, i.e., the work for each sprint proceeds in a pipeline manner, and as a consequence, the work for each sprint is spread over two consecutive timeboxes in an overlapping manner with the next sprint.

Figure2

Figure 2: Sprint pipeline

 What are the advantages of and challenges for the pipeline model of sprint execution shown in Figure 2?

Advantages of the pipelined sprint execution model: 

1AP.   Analysis work proceeds smoothly without blocking the team: As analysis work is carried out one timebox ahead of design-development-testing-defect fixing work for each sprint, the stories are substantially clearer by the time the team enters the Sprint Planning Workshop for each sprint.  Note that the product owner has a full sprint timebox (typically 2 to 4 weeks) to consult with the necessary users, customers and stakeholders in order to answer team members’ questions on stories.  And while this clarification of stories for the next sprint is going on, the team members are not held up or blocked as they are implementing the stories for the current sprint.   Effort estimation and other sprint planning work proceeds more smoothly and can be more easily completed during the Sprint Planning Workshop.

2AP.   Team experiences higher throughput with well understood stories and well-planned sprint: Note that although each sprint work is spread over two timeboxes (as shown by the blue oval in Figure 2), the throughput is not adversely impacted because the team is still delivering working software at the end of each timebox.   In fact, as sprint planning effectiveness and efficiency goes up and stories become clearer, there is a lot less uncertainty about stories as the sprint starts, which reduces impediments, improves team morale and dynamics, and improves team’s throughput compared to sequential execution of sprints.

Challenges for the pipelined sprint execution model: 

1CP.   In each timebox, the team needs to work on two sprints: Although most of the time the team is focused on design-code development-testing-defect fixing work for the current sprint, some of its time must be set aside to analyze the backlog items prepared by the product owner for the next sprint.  This is indicated by the red oval in Figure 2, where the team is spending most of its effort on design-code development-testing-defect fixing for Sprint 2 in Timebox 2, while at the same time spending some effort in analyzing the stories for Sprint 3.   Some teams — especially when they are new to agile — may find working on two sprints in the same timebox challenging.

2CP.   Small risk of doing wasteful work: There may be a small risk of analyzing few stories one timebox ahead of their actual implementation that may end up not being part of the next sprint commitment due to change in priorities as the next sprint planning is completed.   Some people may even object that doing analysis one timebox ahead of the actual implementation could be somewhat wasteful, and it goes against the “just-in-time” agile work philosophy.

I will now explain how to deal with both of these challenges, 1CP and 2CP.

Solution to the challenge of working on two sprints in the same timebox (1CP): The ScrumMaster for the team can help manage work on both sprints in the same timebox (i.e., design-development-testing-defect fixing work for the current sprint as well as analysis of backlog items for the next sprint) by establishing and following a Sprint Cadence Calendar as illustrated in Figure 3.

Figure3

 Figure 3: Two-Week Sprint Cadence Calendar

The two-week Sprint Cadence Calendar has 10 work days, with workday starting at 8:00 AM (0800 hours) and ending at 5:00 PM (1700 hours). The team should allocate about 30 minutes for preparation for the Daily Scrum (DS) meeting and actual attendance by each team member.  These DS meetings should be held every day of the sprint at the same time and place.   In Figure 3, these DS meetings (preparation and actual meeting) are shown as starting at 9:00 AM and ending around 9:30 AM every day.  If you are interested in understanding and implementing highly effective and efficient Daily Scrums, please take a look at my Making-daily-scrum-meetings-really-effective-efficient blog on the subject.  The other ceremonies (Sprint Planning, Sprint Review, and Sprint Retrospective) are also illustrated in Figure 3. If you are interested in understanding and implementing really effective Sprint Retrospectives, please take a look at my Making-sprint-retrospectives-really-effective blog on the subject.

As shown in Figure 3, I recommend that the analysis of backlog items for the next sprint should be scheduled on a regular cadence, where a two-hour meeting is held on every Wednesday (3 PM to 5 PM), as an example.  In these two meetings in a two-week sprint (a total of 4 hours or approximately 5% of the time in the two-week timebox), the product owner and the entire team converse about each story and also confirm each story with its acceptance criteria.  If the product owner cannot answer some questions in the meetings, he/she has adequate time left in the two-week sprint timebox to get those questions answered in consultation with users, customers and stakeholders, without blocking any team member.

I also recommend that the product owner grooms the product backlog and prepares a draft of backlog items for the next sprint on a regular cadence, shown on every Tuesday (3 PM to 5 PM) in Figure 3.  The cadence or pattern for sprint planning, sprint review, sprint retrospective, analysis for the next sprint, and product backlog grooming (shown in Figure 3) is for illustrative purposes only.  Your team should discuss and experiment various sprint cadence options to find the cadence that most suits your needs and choose the cadence that best works for you.  For example, a team may hold Sprint Review and Retrospective for the previous Sprint on Week-1 Monday morning (9 AM to Noon)  followed by Sprint Planning Workshop for the current sprint from 1 PM to 5 PM.  Another team may start the Timebox on a Wednesday (instead of Monday), and two weeks later end it on a Tuesday (instead of Friday), i.e., stagger the start and end of the timebox shown in Figure 3 by two work days to avoid Sprint Planning, Sprint Review and Sprint Retrospective falling adjacent to a weekend day (and tempting some team members to miss them due to their long weekend vacation!).

Regular cadence for all the activities mentioned above minimizes coordination, scheduling and transaction costs; increases predictability through a disciplined schedule published ahead of time for several release cycles (6 to 12 months), and helps an agile team to become a well-oiled machine.  Regular cadence or pattern also reduces unplanned, unexpected, interrupt-driven work that is very damaging due to sudden, unplanned context switches with resulting loss of productivity.

For all these activities shown on a regular cadence in Figure 3, the ScrumMaster working with the team members must set aside adequate capacity: 4 hours for sprint planning, 4.5 hours for 9 Daily Scrum meeting (preparation and attendance), 4 hours for Analysis of the next sprint, 3 hours for Sprint Review, Sprint Retrospective and Celebration – a total of 15.5 hours of capacity is needed for each member for these activities, and that capacity for each member is not available for the design-development-testing-defect fixing work for the current sprint.  If you are interested in calculating the agile capacity of a team after allocating capacity for all these activities, please see my Agile-capacity-calculation blog on the subject.

Solution to the challenge of managing the risk of doing wasteful work (2CP): An important reason why teams fail to deliver stories or backlog items in a sprint is that they were not understood properly when they were committed to the sprint plan during Sprint Planning.  As Dean Leffingwell explains in his Agile Software Requirements book (page 211), from a timing perspective there are three opportunities to do this conversation and confirmation for each story.

  • Prior to the sprint: This is what I have advocated in this blog by stipulating to engage in this conversation and confirmation only one timebox ahead.  Doing it more than one timebox ahead will increase the risk that some of those stories may not get into any sprint commitment as they get trumped by higher priority stories, or they may be removed from the product backlog altogether due to changed business conditions.
  • During the Sprint Planning Workshop:  This workshop is limited to approximately 4 hours for a two-week sprint.  In this short time box, the team has to not only converse and confirm the stories, but do story effort estimation and all other tasks related to sprint planning.  The team may find it difficult to get the time needed to complete the conversation and confirmation for each story, or the product owner simply may not have answers to some of the questions and most likely there is no time in the workshop timebox (only 4 hours) to get the answers by contacting users, customers and stakeholders.
  • During the actual sprint: If the team feels sufficiently confident that conversation and confirmation about a story can wait until the actual sprint due to uncertainty about the story’s business needs, then the conversation and confirmation for that story may be completed along with its implementation in the actual sprint if the story is of sufficiently lower priority.   However, keep in mind that the story was committed to the sprint during its sprint planning without proper conversation and confirmation (and hence with either no estimate or a very rough estimate).  This situation carries some risk and is not ideal.

I recommend that you complete the analysis of as many high priority stories as possible one timebox ahead of the sprint in which they will be implemented, try to complete as much analysis as possible for some of the lower priority stories during the Sprint Planning Workshop, and leave very small number of analysis questions to be resolved during the actual sprint if you have to.

In my coaching engagements, I have seen agile teams transitioning from sequential sprint execution model to the pipelined sprint execution model after 2 to 4 sequential sprints under their belt, and then with experience (inspect and adapt) getting better at the pipelined model.  This is kaizen (continuous improvements) in work, resulting into higher throughput, improved quality, and increased team morale and work satisfaction.

Have you tried the sprint pipelined model?  What is your experience?
Are you interested in starting your own sprint pipeline?

I would love to hear from you either here or by e-mail (Satish.Thatte@VersionOne.com) or on twitter (@smthatte).

 

Posted in Agile Adoption, Agile Benefits, Agile Coaching, Agile Development, Agile Management, Agile Methodologies, Agile Project Management, Agile Teams, Agile Training, Scrum Development, Scrum Methodology | Leave a comment

The Agile Coach on Production Support

One of the biggest struggles I’ve seen in organizations adopting Agile is in the area of Production Support. Every organization that has a product to support has to manage this. It’s a critical part of the business. There’s a lot of responsibility to manage a 24/7 Production environment. The middle of the night calls, working on code you didn’t create. Speediness, precision, reaction time and problem-solving are crucial.

productsupport

The struggle typically comes in the form of pulling people away from active Scrum teams to make whatever hot fixes are necessary. This is clearly disruptive to the Scrum development team. Oftentimes, a team member is being pulled away to work on something that’s very unpredictable. Who knows how long they could be gone from the team; an hour, a day, a week? This disrupts our rhythm and velocity. It makes planning difficult. Team cohesiveness suffers. The person getting yanked to do the Production work usually isn’t too happy either. Context switching makes them less productive. And in the end, we actually get less done!

Alas, we need to get these ongoing high priority bug fixes out the door asap. And we need the ability to re-prioritize any time. We need focus. And we know that 2 week sprints aren’t a good fit.

So how do we combat this? How can we keep our Production environment up to speed, while also allowing our Scrum teams to develop that stuff they’ve committed to getting done for their Product Owner?

My preference, and one that I’ve seen work well in many organizations, is to create a new Production Support team that works these hot fixes as part of a Kanban effort. The only negative feedback I’ve heard on this is that it seems like punishment to some (think of the Gulag in Northern Syberia). To combat this feeling, we’ve tried cycling folks on and off the team so they don’t burn out. As any good Managers knows, it goes a long way to show your appreciation to this group in some way. Maybe a really nice work environment, new laptops, snacks/drinks, etc. A sincere pat on the back also works wonders. Get creative. Additionally, there may be some folks that don’t fit well in your new highly collaborative team culture. They’re very smart folks, but more of the lone wolf variety. This team could be a natural fit for them.

At the end of the day, technical debt is something that will keep us in this death spiral. We want fewer bugs in Production. In order to get out of it, we need to improve our technical practices, our code quality, our testing, our architecture, and our design. It’s hard to make any progress if we keep patching up something that’s not good to begin with. Sometimes it’s just easier in the long run to scrap it and start fresh (I know, that’s a hard pill to swallow).

How do you handle Production Support in your Agile environment?

Posted in Agile Development, Agile Management, Agile Teams, Scrum Development | 2 Comments

The Missing Agile Value

This post was originally published on ItemsOnTheLeft.com.

Author Carol Dweck has completely changed the way I approach the world.

I’m a smart guy. I’m no genius but I’m pretty smart. Through most of my life, I’ve been able to get by just by being smart. For the most part it has turned out to be a pretty good strategy. I complete tasks in less time by thinking about them longer, I demonstrate industry knowledge (thus impressing my bosses) because I can hold a lot in my big fat brain. The problem is, I allowed the world around me to turn my smarts into my identity. It became my brand, and I felt a constant subconscious urge to protect that brand. As a result, I would avoid any attempt at a challenge to my intelligence. Unfamiliar things were anathema because not knowing about them made me look not smart. I avoided anything above my cognitive pay grade, and chose the activities that allowed me to shine.

Kinda limiting, don’t you think?

Enter Carol Dweck. She wrote Mindset, a book I find myself recommending in just about every conversation I have. In it, she describes me exactly. I had, as she describes in her book, a fixed mindset. Someone with a fixed mindset believes that intelligence and abilities are fixed; you’re either born with them or you’re not. A growth mindset, however, is one that believes that intelligence is not fixed and that, with enough effort and grit, anyone can be brilliant. The message isn’t new; it’s basically a very detailed version of, “Whether you think you can or you can’t, you’re right.” But what is new, as she explains in her book, is the science and evidence behind that way of thinking.

She compares John McEnroe (fixed mindset) to Michael Jordan (growth mindset). John McEnroe would blame everyone but himself when he lost a match, but Michael Jordan consistently put in the effort to become the best basketball player ever. McEnroe wouldn’t allow himself to be labeled as someone who has something to learn, he considered himself a born tennis great. Jordan, on the other hand, was always learning, always trying to make himself a better player.

Since reading the book, I’ve looked at the world in a completely different way. Instead of looking for opportunities to show off my intelligence, I’m looking for opportunities to grow my intelligence. Instead of gravitating toward subjects with which I’m already familiar, I’m entering into new and unfamiliar domains. I’m learning about sales. I joined an indoor soccer team. I’ve always considered myself rather bad at sales and just plain awful at soccer. I’m no longer embarrassed to say that I don’t know something. Instead, I’m eager to learn about it. I don’t allow failing to result in labeling myself as a failure. Instead, I learn from it.

I value learning. And there’s a lot to learn in the domain of software development. Because it’s hard.

I believe the creators of the Agile Manifesto value learning as well. They just went about expressing it in a different way. Take a look at the first sentence:

“We are uncovering better ways of developing software by doing it and helping others do it.”

Imagine, instead, if this first sentence was written like this:

“We have uncovered the best way to develop software through academic research.”

We are uncovering better ways of developing software. We’re still trying to figure this thing out. We’re still learning. Just like doctors who say they “practice” medicine because they haven’t perfected the science, I think that we’re practicing Agile because we haven’t perfected the process. And I don’t think we ever will. That’s why we always have to be learning.

By doing it and helping others do it. By digging in, failing, and learning – we’re putting our reputations on the line by experimenting with software development approaches in settings where money is at stake.

Learning is everywhere in the Agile mindset. We learn from our customers through rapid and frequent feedback. We learn from each other through regularly scheduled retrospectives. We respond to change because we learn about shifts in the market. We rework and refactor because we learn that there’s a better way to lay down code. To truly be Agile means to be in constant learning mode. To be Agile requires a growth mindset.

Have you noticed that the term “best practice” is hard to find in the Agile canon? That’s because there really are no best practices. We implement, we retrospect, we tweak. With all that tweaking, how could we ever settle on a best practice? If we’re too focused on implementing the best way, we’ll never find the better ways.

I offer an additional Agile value: Learning over Best Practices. While there is value in best practices, we value learning more. I’d like to know where you stand on this. Please drop a comment or hit me up on Twitter at @johnkrewson. Maybe I can learn something from your feedback.

Posted in Agile Adoption, Agile Benefits, Agile Coaching, Agile Development, Agile Management, Agile Methodologies, Agile Project Management, Agile Software, Agile Teams, Iterative Development, Lean | 9 Comments

Why Your Organization Struggles with Agile

StruggleIt’s the basics that are killing your organization’s Agile effectiveness.

You used to practice them, but then got sloppy.

Or you never really learned to practice them that well before the need to scale was pressed upon you, and now things are growing up and out too quickly to go back and shore up the details.

How do I know this?

I’m just playing the odds that your organization probably falls into that very large group that is struggling to realize the potential of Agile.  And I’m considering what I observe all too frequently to be at the root of the struggle.

We all know what we have to do if we want to get in shape, right? Eat better, eat less, and exercise regularly.  Simple.  So why does the fitness industry rake in tens of billions of dollars annually, while the incidence of obesity and diseases related to lack of fitness keep increasing?

Want to build a financial nest egg? Save and invest more, and consume less, of course.  Again, very straightforward, but current research indicates that 76% of Americans are living paycheck to paycheck. Why?

For both of the above, the answer is, more often than not a) the delusion that “the normal rules don’t apply to my situation”, and/or b) a lack of discipline.

Ineffective Agile adoptions, including enterprise-scale transformations, can be traced to these same two causes. In fact, this applies to most things that we human beings don’t follow through on.

So why am I pointing out something so obvious and so universal?

Because I don’t want you to fail.

I don’t want you to run out and buy the Agile equivalent of a Treadmaster 9000 and a “Get Rich Tomorrow” home study course, only to find yourself sick and broke a year from now.

Is your organization holding onto collaboration-killing and throughput-throttling processes, based on the rationale that your business domain or product or technology mix is more complex than that of everybody else who is practicing Agile?

Is it shaving the sharp corners off the parts of Agile that are uncomfortable, either leaving gaps or replacing what was removed with something softer and more accommodating of the status quo?

True, successful Agile enterprises are continuously inspecting and tweaking how they do things.  That’s how they get better.  But they are tweaking the application of the fundamentals, not the fundamentals themselves.

Even “seasoned” Agile organizations plateau, and then seek out some advanced Agile concept or technique that is guaranteed to take them to the “next level”.  But there is none.

No professional sports team’s coach says, at a post-loss press conference, “Well, we were just one or two trick plays away from winning this.”   No, what they actually say is, “We didn’t execute on the fundamentals, and it cost us the game.”

The secret to Agile success is that there IS no secret.  Success comes through relentless improvement in the application of a few fundamental concepts and values.  Your situation isn’t the rare exception.

Yes, this can be challenging, especially when the impediments that need to be addressed are rooted high-up in the enterprise.  If it was easy, every organization would be wildly successful, and lots of Agile consultants I know would be running Tilt-a-Whirls at carnivals all over this great country of ours.

But that doesn’t mean it isn’t worth the effort.  If you want to succeed, you don’t really have a choice.

Posted in Agile Adoption, Agile Benefits, Scaling Agile | Leave a comment

Strengthen Your Discovery Muscle

Guest post by Mary Gorman & Ellen Gottesdiener of EBG Consulting

 

In a recent interview in the New York Times, Panera Bread co-CEO Ronald M. Shaich talks about the importance of de­veloping an organization’s “discovery muscle” as well as its “delivery muscle.” [1] Most companies have worked hard to perfect delivery—how they get work done—he says, because delivery “feels rational, people feel much safer with it, and you can analyze it.” But discovery—the activities you undertake to define or change your product, service, or market—is about “leaps of faith. It’s about trusting yourself. It’s about innova­tion.” The key, Shaich says, is for the discovery muscle to be at least as strong as the delivery muscle.

He took the words right out of our mouths. This need for balance between discovery and delivery applies in spades to software development. Our new book, Discover to Deliver: Agile Product Planning and Analysis [2], explicitly makes the case for equally balancing your commitment to these key ac­tivities. We define the relationship between them: In lean/agile software development, discovery and delivery are interwoven, interdependent, continuous activities (see figure 1). Each feeds the other.

Figure 1: Discovery and delivery are a continual process.

figure 1

 

 

Traditionally, software teams have been out of balance—strong on delivery but weak on discovery. As a result, they tend to deliver technically excellent software that, unfortunately, may solve the wrong problem, possibly lags the market, or oth­erwise falls short of meeting the stakeholders’ real needs.

If your team needs to develop its discovery muscle, it’s not really about making a leap of faith. It’s more about making a leap of learning. Let’s look at why and how.

Context Counts

Many teams set themselves up for failure by not including discovery in their process from the very beginning. Before you begin talking about product options (aka requirements), the stakeholders need to hammer out a product vision and goals.

One of your most useful discovery tools is constructing and asking good questions to set the context and determine your mark. What is your company strategy, and how does your vi­sion for the proposed product align with it? Should the strategy be revised in light of recent developments? What is your problem or opportunity? What is the competition doing or not doing? What is your competitive advantage? Are you being too safe? Might there be customers beyond your current market? Who cares?

context counts

Figure 2: The product partners need to represent diverse viewpoints.

The vision activity should include people who represent three realms: the business, the customer, and the technology group—all of whom we call the product partners (see Figure 2). They need to collaboratively contribute to the vision.

The Lean/agile practices we use position value as the chief criterion for planning which product options to develop next. Of course, you’re not working at the level of product options yet, but now—while you’re developing the product vision—is the time for the partners to define their value considerations. A few examples:

Customer Value Consideration: Save time, money, and frustration.

Business Value Consideration: Support our growth strategy.

Technology Value Consideration: Ensure a scalable technology platform.

 

Working Together

Discovery is a team sport, not a spectator sport. Your dis­covery team must include diverse voices and perspectives. The partners collaboratively expand their thinking, look at the problem with fresh eyes, and consider new or unique possibilities. They reach far and wide. They listen to differing perspec­tives and reach agreement. You gain two benefits: (1) you exploit the wisdom (attributed to Aristotle) that the whole is greater than the sum of its parts, and (2) the product partners collectively own the discoveries.

As you collaborate in discovery, it’s important not to bow to conventional wisdom. It’s easy for your discovery muscle to shorten and tighten if you don’t stretch it. Instead, critique the way you’ve always done things. Be courageous, creative, and curious. Find out why. Moreover, as Shaich notes, defying con­ventional wisdom may help you discover something that gives you a competitive advantage.

Holistic Discovery Practices

Discovery engages the partners in learning and possibili­ties—it demands problem-seeking and solution-finding. To that end, your discovery process should address the product needs for each of what we call the “7 Product Dimensions” (see Figure 3 below).

Figure 3: Discover all 7 Product Dimensions.

holistic discovery practices

Discovering all 7 Product Dimensions gives you a holistic understanding of the product’s functional and nonfunctional needs. You explore options within and across each dimension. This cross-dimension perspective helps inform and balance your discovery.

During a recent discovery workshop at a health care pro­vider, the partners quickly identified “obvious” users such as health care members and health care providers (e.g., physi­cians). Digging deeper, they discovered the health care medical director, who has unique product needs. Then they considered the users in light of the other dimensions and discovered new interfaces and environments, along with related actions, data, control (business rules), and quality attribute options. This discovery work provided a number of benefits. The partners’ shared understanding of the broad range of product possibili­ties helped shape the overall architecture, saving future rework. It guided their research on usability needs for complex data-visualization interfaces. And they reduced risk by collectively selecting the high-value options for their first release.

In conjunction with the 7 Product Dimensions, you use the “structured conversation” to frame your discovery sessions into three activities: explore, evaluate, and confirm (see Figure 4 below).

structured conversation

 

Figure 4: The structured conversation guides your discovery work.

The structured conversation is a lightweight framework that guides the product partners as they learn about the prod­uct’s possibilities and decide what to deliver. You explore op­tions for all 7 Product Dimensions. As you evaluate the ben­efits and risks of each product option, you use the partners’ value considerations to identify high-value options. You also confirm the partners’ understanding of the options.

And importantly, at each new planning session you’re open to exploring, evaluating, and confirming new product options, using your learning from prior deliveries. Thus, the structured conversation helps you balance your discovery and delivery muscles by moderating between the expansive thinking of dis­covery and the more focused thinking of confirmation and de­livery.

Engage Creatively

Discovery is the rich interplay of creativity, new or expan­sive thinking and human-centered design. You stretch your discovery muscle, making way for purposeful serendipity.

This aspect of discovery is often referred to as “design thinking,” a newer term for diverge-then-converge prac­tices that inspire, boost, and challenge the partners. Design thinking draws from an amalgamation of disciplines such as visual design, professional facilitation, architecture, industrial engineering, contextual inquiry, participatory design, impro­visation, learning games and simulations, and the burgeoning innovation and creativity movement.

Discovery goes beyond writing stories. Design matters. A lot. Your product’s look, feel, color, and aesthetic appeal—its visceral likeability—matter. Space and tools matter, as well. You “uncube” physical space so that people can conveniently and extemporaneously interact as they converse, sketch on posters, walls, or whiteboards, and select from and play with colored posts, markers, and glue to find possibilities and ex­plode problems.

To get there, you can draw from the family of facilitated workshop activities—variously called collaboration activities, serious games, Innovation Games, and more—to spark possi­bilities and yield serious outcomes. You can also use sketching, brain writing, affinity mapping, or card sorting activities. Tech­niques such as personas, role play, contextual inquiry, empathy maps, and journey maps help you gain affinity with your users, and you can employ analysis models such as prototypes, state diagrams, data models, and dependency graphs to tap into vi­sual thinking.

tools and techniques

Figure 5: You can use various discovery tools and techniques according to the planning view.

 

 

 

 

Calibrate Your Discovery 

You need to adjust your discovery scope depending on your planning horizon—what we’ve termed the Big-View, Pre-View, and Now-View (see Figure 5 above). You might not necessarily start from the top and work down, as long as you have a clear defi­nition of your discovery scope.

In the Big-View (the longest planning horizon, up to two years), your discovery muscle needs to be loose, flexible, and far reaching. At this planning horizon, you discover high-level, generalized possibilities for the product, across all 7 Product Dimensions. You might want to start discovery with a vision statement for the product, or your discovery might lead you to craft the vision.

In the Pre-View (the middle distance, or release view, pos­sibly a few weeks to a month), your discovery muscle is toned and controlled. Your discovery is framed within a clearly de­fined space to explore, evaluate, and select high-value product needs to enable planning for the next release.

In the Now-View (the shortest view, typically the next itera­tion: days or weeks), your discovery muscle is taut, ready to spring or sprint. You are focused on a narrowly defined space. You need to discover and define high-value product require­ments in sufficient detail to enable immediate development and potential delivery.

Training Your Discovery Muscle

To get the most from discovery, be prepared to stretch, reach, bend, and twist the way you think about your product. At first, you may find training your discovery muscle uncom­fortable, even unpleasant. Or the partners may not be willing to discover together. Yet, regularly exercising your discovery muscle improves flexibility and range—you will see your busi­ness through different eyes. You will develop skills in discovery and innovation, building muscle memory so that discovery be­comes natural, seeming to progress without conscious effort.

Warning: As with any routine, your initial enthusiasm for discovery may dim with time and repetition, and your discov­eries may be less powerful. If that happens, look for new ways to spark creativity. Vary your techniques, inject new ones, and play innovation games. Switch roles, and take on a different perspective. Get out of your comfort zone.

 

“Your discovery muscle needs to be fit and ready to move, explore, and innovate to exploit opportunities.”

 

Reaching a Shared Understanding

The 7 Product Dimensions and the structured conversation are essential tools that enable the people in the three partner realms to agree on which discovered product needs are high value. The 7 Product Dimensions construct, for example, em­ploys a visual language that all the stakeholders can use in talking about the product. And because of the structure in the structured conversation, the partners become intimately ac­quainted with the incremental nature of the Lean/agile process.

So, what’s the biggest mistake we’ve seen that obliterates the benefits of these powerful tools? Failing to include the right people from beginning to end. The resulting siloed conversa­tions cause people to develop different—often conflicting— definitions of the product to be. Discovery becomes haphazard and undisciplined, scope changes often, and people retreat into the apparently safer, saner world of delivery. As a result, op­portunities to make a great product fizzle out.

It’s a Process, Not an Event

At any given time—this year, this release, this iteration— you may discover new product possibilities. That’s the nature of discovery. This means that your discovery muscle needs to be fit and ready to move, explore, and innovate to exploit op­portunities.

In the process we advocate, you move your discoveries into delivery so you can validate the value of the product options you chose. You assess what you deliver, and you validate what you have learned. Did the result deliver the anticipated value? If so, keep doing what you’re doing. If not, then loop back using your validated learning to feed subsequent exploration and experimentation.

Successful software teams deliver great products because they invest in ongoing discovery as well as delivery. With fre­quent exercise, their discovery muscle becomes stronger and more limber and works smoothly in tandem with their delivery muscle.

Want to learn more? Contact us: 

mary@ebgconsulting.com

ellen@ebgconsulting.com 

 

Posted in Agile Adoption, Agile Development, Agile Methodologies, Agile Training, Lean | Leave a comment

Organizational Learning Always Precedes Agile Maturity

I’ve become increasingly convinced that a lack of learning is one of the largest inhibitors of agile transformation results.  One can argue that we are at, or nearing, the end of the knowledge era.  Knowledge is ubiquitous.  Simple possession of knowledge is not sufficient for either the individual or the organization.  Today’s rapidly changing business climate requires the coalescing of knowledge and experience into rapid learning that can be applied to problems and opportunities we can leverage for business value—quickly.

The amplification of learning is a key principle in lean and agile methods.  However, this is where traditional organizations making the switch to agile can very easily get in their own way if they’re not deliberate with their intentions.  Some of the best learning is obtained through failure.  For example, Thomas Edison failed several thousand times while attempting to find the correct material to create a filament for his incandescent bulb.  That means he learned several thousand ways of incorrectly creating an incandescent light bulb.  Large organizations strive to improve profitability and success through minimizing risk, which often results in a palpable fear of failure.  This fear can metastasize in an organization and impede learning and innovation.

So, how does this apply to agile transformations?  I’m sure everyone reading this blog has either read or heard someone say, “agile is not something you do; it’s something you are—a state of being.”  While I believe that’s true, it’s also a new way of working, one that comes with risk and inherently challenges the status quo.  Very frequently I sense an attitude in organizations that agile is “something the developers do” or “a new process that is being adopted in IT.”  The problem with this naïve thinking is that it will ultimately erode the results an organization might obtain, and frequently leads to failed agile initiatives.

For maximum impact and long-lasting results, agile should be embraced throughout the entire value stream.  This means from front-end customer contact (through Sales, Marketing, and Product Management organizations) all the way to the back-end of the value stream (IT operations and post-production support).  To do this requires a fundamental shift in how organizations are structured and operated.  It doesn’t have to happen all at once, but it does have to happen on a larger scale than the team level.  In fact, perhaps we should favor the scaling of agile values over the scaling of agile processes and practices.  Rather than, or perhaps before, asking how we can scale agile to the enterprise level, we should be exploring how we can scale agile thinking to the enterprise level.  Remember, individuals and interactions over processes and tools?

On the individual level, team members are sent to agile courses and are expected to deliver twice as much in half the time with a quarter of the budget.  Yet, when the course ends they are thrust back into an environment that has been structured to minimize risk and optimize predictability through rigid processes, massive reporting hierarchies, and unwieldy governance.  People tend to take the path of least resistance.  Therefore, especially when the pressure is on, they will do what’s necessary to get their jobs done.  Unfortunately, this often means working in the same manner they have always worked (status quo).

I think many of us can identify with these issues in some fashion.  It’s easy to become complacent, apathetic, and complain.  We see the problems around us.  But, what exactly can we do about it?  How can we, as individuals, impact change on a larger scale?  First, it’s important to understand that agile methods are exceptional at illuminating dysfunction.  I’ve heard individuals say, “how can we possibly deliver a working and fully-tested feature in two weeks?”  My response is typically, “working the way you currently are, you probably can’t.”  Expecting a major improvement in delivery without simultaneously experiencing disruption is unrealistic.  When organizations and teams begin implementing agile they will undoubtedly experience issues and frustration.  They will also make mistakes; this is learning.

The important thing to focus on is minimizing the probability that the same mistake will be made twice.  Too often the callous finger of blame is pointed at agile as either not being applicable (it just doesn’t work in our situation) or as the root cause of the issues.  We need to help our organizations understand that agile is not the root cause of many of these problems.  Make your first question, “What about this situation might be giving us pain?”  You will often find that you are clinging to practices that are grounded in traditional thinking but that run counter to the 12 agile principles outlined in the agile manifesto.  Challenge your teams to discover why they are having issues.  Retrospectives provide an excellent avenue to amplify learning.  And don’t be afraid to actually try something.  Learning is a verb; you must act on knowledge gained to realize improvement.

To help our organizations improve we need to conduct retrospectives at many levels within the enterprise, not simply at the team level.  To amplify learning we must help everyone, including the wider organization, become reflective.  Retrospectives can be applied to every level throughout the organization, especially at the leadership level as the organizational hierarchy plays a major role in enabling success.  If you’re a leader (and everyone certainly can be if they choose to be) and you’re not performing the actual front-line work of creating products and/or services that your customers consume, remind yourself often that you DO NOT deliver value.  Rather, you are a primary enabler of value delivery.  Help keep the organizational machinery well-oiled and finely tuned.

Finally, take personal responsibility for helping your organization learn and grow.  Use your network to help you do this.  In one organization I worked with I created a monthly forum where well-known agile thought leaders were invited in to present new ideas to the organization on a wide range of topics.  I did this as a hosted web conference that was recorded and archived for those unable to join live.  Providing this access to thought leadership was inexpensive and helped others immensely.  It also helped the presenters by providing additional exposure and even gained a few of them business engagements at the company.  Don’t be shy in reaching out to these individuals as most are approachable, personable, and eager to help.  You simply need to ask.

Try some of these practices to help your organization increase agile maturity.  Become a thought leader yourself and strive to learn all that you can.  But don’t stop there.  Propagate your learning to others.  You don’t need to do this through formal classes.  It can be done in simple hallway conversations and daily interactions.  Organizational learning is the aggregate of the actualized knowledge of every individual within the organization.  In its absence agile maturity will stagnate.

Posted in Agile Adoption, Agile Coaching, Agile Management, Agile Methodologies, Scaling Agile | 1 Comment

VersionOne – An Idea Worth Making Simple

Guest post by Michael Swansegar

“What’s the most resilient parasite?  An IDEA.
 
A single idea from the human mind, can build cities.
An idea, can transform the world, and rewrite all the rules…which is why, I have to steal it.
 
Never recreate from your memory, always imagine new places.
 
He’s hiding something and we need to find out what that is
 
This was not a part of the plan.
 
Wake me up!  Wake me up!”

What if I told you that you have heard those words before?  Well you have, for a good portion of 2010. http://tinyurl.com/d8x8y83  Yes, this is the script for the trailer from the movie, “Inception.”  This movie captivated audiences across the globe.  Why?  It was structured to help people understand we are motivated by a highly secure, deeply entrenched idea that shaped our lives. Everything we do in life is built around ideas. Ideas are hard to forget, ideas change the world and inspire companies, nations, families and the most important person, YOU.  You were meant to change the world.

Well this script runs two additional things: it runs the agenda of an agile cultural event called Project Inception but this ‘script’ is the basis of how you could potentially view VersionOne.  As I take you through this ‘idea,’ I hope you see as I do, not only the value of an agile event but moreso the value of VersionOne, their culture, their product, and their belief in someone that can change the world, YOU.

Forget what you think you know.  Wait a second, that’s hard to do isn’t it?  Let’s do something different; let’s replace our focus on something simple.  The idea is this… replace every scripted plan, every requirement document, every business meeting, every statement of work with a simple question.  That question is simple yet bold, “Is this valuable?”  Is it, the product or service, valuable?  Let’s take it further. Are you acting and building in a valuable way?

Start-with-Why-Screenshot

Simon Sinek has a wonderful book called Start With Why.  In that book he relates a number of scenarios where companies became market dominators if they focused on why, the motivation, the ‘value’ concept, the limbic brain.  When someone says, “This doesn’t feel right…” that is a limbic brain response.

Limbic brains feel value, but can’t necessarily quantify it.  This is where you start – with agile, with our event and with VersionOne.  You start with feeling something about your product, your service, your partnership and, most importantly, with your own motivations.

Where do I as an outsider see VersionOne?  Let’s take VersionOne’s tagline which states, “Agile Made Easier.“  AHA! Something real,something that makes you feel right.  If VersionOne said, ‘Agile Made Easy’ you wouldn’t feel right about that statement.  If you said agile was “easy,” someone might look at you and say, “Who lied to you?”  They are motivated to make agile easier.  That isn’t necessarily quantifiable with fact.  Making something easier is very subjective, but the IDEA is VALUABLE.  The idea is to make something easier, make it valuable, make it feel right so it is natural to you.  So the parasite has leached on to VersionOne and hopefully on to you.  Make things easier, make them valuable, period.

VersionOne takes it further. They believe, just as I teach at Project Inception, that agile is not about process.  The agile process simply comes along for the ride.  Agile is about loyalty, customer loyalty, your loyalty.  There is a reason why Apple has a cult-like following: they “think different.” They don’t tell you what they have; they tell you how they feel.  Apple’s products make you feel something. VersionOne produces services and an agile project management tool set that is built to inspire loyalty. BS?

Let’s take an analogy for a ride, shall we?  You own a mansion with a perfect yard (don’t we all?) and you never live in the house because you have to constantly work to pay for the house.  So what do you do?  You hire a neighborhood kid to mow the grass.  You may be rich, but you believe in using someone nearby – call it “co-located resources.” Well each week, this kid cuts your grass too low.  In fact, imagine you live in southern California where they have no water but plenty of forest fires.  So you know your product of value (the grass) will die a quick death.  Each week you have to over-water the grass so it doesn’t get scorched; call it a broken business process due to a P.O.S. product. Each week you give feedback and the kid doesn’t listen. Each week your grass is getting burned. After the 4th or 5th week, your neighbors are packing up their golf clubs and laughing at you since you can’t join them because your lawn is on the brink of death. Who is the idiot now?  Do you feel loyal to that kid anymore? Does that kid feel loyal to you?

How the hell does this relate to VersionOne? Well agile is about building something valuable to inspire loyalty, right? Every few weeks the product is ‘mowed’ by virtue of a product demo. Each iteration, as it were, you get burndown charts and burnup charts. VersionOne excels at a Scrum value called ‘Openness.’ Their agile project management tool brings visibility to either the problems or the successes.  If you chose to show your product and your status by means of an open tool like VersionOne, agile is easier because the parasite (value) is identified faster. Why?  ‘Openness’ assumes some other Scrum values of hearing your customer’s feedback with ‘Respect’ and then having the ‘Focus’ to hear what they feel in their limbic brain. This takes ‘Courage’ to hear painful failures at times, but this allows you to finally ‘Commit.’ You commit to building the right product and making the changes that will inspire the loyalty of that client.

Brain Science Source why-agile.com

Brain Science
Source why-agile.com

“Why”/The IDEA = Agile Made Easier = Value

“How” =  By holding true to agile values and principles in our services and tangible product lines.

“What” = We have a tool that shows value defined via stories, charts, graphs, planning, idea management and, most importantly, common sense.

Welcome to Maloney’s Rule, or “Accelerating Diffusion of Innovation.” In short, Marketing 101.  Your customers are hiding something from you.  You need to perform Inception on them. Still don’t know what that means? Watch the movie!  It means you go into someone’s dream/head and steal or replace an idea with your own. No, I am not encouraging espionage in companies, but I am encouraging you build your products and services to invite a customer to turn into a partner. Seth Godin (famous marketer) partly calls this stage the title of his book, Permission Marketing. When a customer “invites you” to come into their business, to see more problems and discuss solutions as a partner, you have reached permission marketing. When products or services have reached this stage, you look at Maloney’s Rule and see why it is carried through the curve.

Let’s look at the iPhone crazies for a moment:

Maloney's Rule / Bell Curve Source why-agile.com

Maloney’s Rule / Bell Curve
Source why-agile.com

GEEKS

They value being first and “early adopters.” They have a strong limbic feeling to the iPhone so they will buy the iPhone 6 the moment it comes out.  They will tell their friends if it is awesome. They blog, they tweet and they actually attend that two-hour commercial called the Apple Conference. Their limbic brains say “the product feels right; the only losing move is not to play.” 

GENERAL PUBLIC

They value a product that fits a business need. They check to see the product ratings. They check their wireless contracts and ask themselves, “Do I really want to stay with AT&T or should I wait so I can move to Verizon?”  Their limbic brains say, “I don’t know about this contract; it doesn’t feel right.  Let’s wait to renew.” 

GRANDMA

They value family and they aren’t too sure if technology is needed to actually come visit someone in person. They most likely won’t buy it. Heck, most of these people can’t even see. They still use AOL for shopping and play Bingo on Fridays.  Their geeky grandchild will give them the iPhone 5 or 4 or 3 saying, “Hey grandma, you want to see your grandkids grow up? I will send a picture of them to you every week.” Meanwhile, grandma can’t find the icon labeled ‘Messages’ to actually see the photograph.

So each user type, each partner on the curve, has different value statements.  This is what they are hiding,their IDEA, their VALUE statement.  Hello, Product Owners! Go extract that info, will ya?  Hello, VersionOne! Thank you for making a product with Ideas Management from the ground up.  You didn’t white-label some tool and slap it into your product, claiming it was yours.  Although if you were smart (competitors), you wouldn’t slap anything and take the risk of claiming it was yours.  VersionOne built Ideas Management inside the product because it is part of their DNA — to identify valuehence making agile easier.

Project Inception spends an entire morning on this topic so this is just the tip of the iceberg. It is good to know that if this just scrapes the tip, VersionOne must have an iceberg of hardened values we have yet to harness for our benefit.

Welcome to “top-down planning” or “the rolling wave approach” (PMBOK). Time to bring in the agile poster of VersionOne, which you can get here:  http://pm.versionone.com/AgilePoster.html

VersionOne stresses top-down planning in one of its truest forms. Noticed first, “Agility is…” starts at the top focused on the fuzzy things such as goals and vision.  Now you ask yourself, “How would I like this product released to inspire loyalty and encourage the spirit of collaboration with feedback loops?” VersionOne calls that the Release loop, which has its own estimation and lightweight planning stage.  Working with the customer to decide how they want to define value and potential delivery via feature-based delivery (see Blizzard Entertainment) or timebox-based delivery will inspire them to be a part of your culture and success stories.

Now comes the fun part: the first layer of reality, the “Iteration” phase where a review of the product and inspections or “retrospectives” give the partner visibility into who we are and why we exist, day in and day out. When a partner can open VersionOne and see human behavior via burndown or burnup charts, they are fully invested in your company — monetarily and mentally.  When a partner is interested enough to listen to how the team could behave better in a retrospective, you know they are no longer a paying customer but a loyal partner.  This loop is huge; it is where a business ‘fluffy’ executive can see first hand the impacts of business and technical competence colliding. VersionOne handles this phase with care and “Openness” to allow for visibility into the barriers to meeting defined value. The more visibility and accountability at this phase, the more you can leverage agile. To VersionOne’s primary parasite, it makes “agile easier.”

Looking into the daily activities, we can project into the future. We aren’t recreating from our memory; we are using data of there, here and now to “imagine new places.” The place, as it were, is the parasite… the idea of value in our partner’s mind for which we are constantly striving. Notice at the end, “Agility is… working software.”  That is all that matters; does it work? “Work” is defined as meeting the parasite — the idea of value, not just from a feature standpoint but also from a perception mindset.  That is really hard to do.  Again, agile is not easy; it can only be made “easier.”

How often have you heard this before?  It is used so often as an excuse to fail. Many people think it is a protective coat of armor. Well, when you are under water, the last thing you want is armor. You want to take everything off, so to speak, any weight, any unnecessary supposed asset – so that you can tread water. Don’t use this comment as an excuse to fail. If life were always planned, it wouldn’t be worth living. If agile were easy, everyone would do it. Better yet, everyone would be doing it properly. Look no further than VersionOne’s homepage.  I am not sure who approved this design, but if it was Dan, props to that guy. The message is loud and clear. Below is a screenshot taken of VersionOne’s web site.

versionone-home-page

 

“This wasn’t part of the plan!”

That’s OK, as long as all the projects and all the teams are in one place.  We can adjust; we can see the inter-dependencies. Besides, if this adjustment couldn’t be foreseen, we have bigger problems than the plan itself. We apply strategic thinking to our out loop, and let the vision and idea direct every motivation of our teams by bringing them together to believe in something.

“This wasn’t part of the plan!”

That’s OK. We have visibility across the entire software lifecycle. We see how test-driven development can catch changes and its associated risk nice and early. We see via in-depth reporting how the human impact will be felt at different layers on different teams. We can adjust the impact to be handled by the mature teams while protecting the ones that are fragile. We can see the output and protect its quality through our visibility. We are strong when most open and vulnerable to factual trends.

“This wasn’t part of the plan!”
 

We believe in in commitment, respect, focus and courage.  You can’t have that without collaboration, and that is why we have views between our teams (agile team software with “TeamRooms“) and Kanban boards. We aggressively hold each other accountable by openly challenging each other to hold their commitments. We collaborate naturally, but use agile team collaboration software to exemplify our natural-born gifts. We are focused on the goal at hand, and we allow nothing to creep in secretly by forcing our organization to openly show what is in the iteration and how we task each other to our most efficient capacity.

 
plan pencil
 
 
“This wasn’t part of the plan!”…  
 
“You are correct, and that is why we are changing the plan.  We work on value, period.  Our partner trusts us to see reality and their needs change.  Perhaps you should start using a pencil
 
…instead of a pen next time?” 
 

You see this in your typical workflow of agility at the customer demos.  The business doesn’t like to be surprised, so this shouldn’t be the first time you share your findings with customers. However, you can find blog posts on demo day all over the place. Let’s bring this back home instead of repeating content you have read elsewhere.

Inception: we have hopefully leached a parasite on you — an idea focused on value. In the sense of agile, we want you to feel the need to find what your customers are hiding… that tangible idea of value buried beneath layers and layers of security.

We have talked about looking at the limbic brain and understanding your partners’ feelings, and from a marketing angle why you can’t ignore the geeks who believe in something. We have carried the parasite forward, not wanting to latch on to the past, but always imaging new places. The place of value our customers dream about and our interpretation of that dream can be obtained by striving to have not only a process, but a culture centered around agility.

Agile Made Easier

Agile Made Easier

It’s time to wake up and understand a cold, hard truth: agile is not, nor will it ever be, easy.

However, Project Inception and VersionOne have a simpler goal: agile can be made easier.

Posted in Agile Adoption, Agile Benefits, Agile Development, Agile Software, Agile Teams, Scrum Development, Test Driven Development, Uncategorized | Leave a comment

Valuable Agile Retrospectives: How to Do Them?

Guest post from Ben Linders, Netherlands-based Sr. Consultant, InfoQ editor and bilingual (Dutch & English) blogger

At the end of an iteration, typically two meetings are held: The sprint review (or demo) which focuses on getting product feedback, and the agile retrospective which focuses on the team and the process used to deliver software. Agile retrospectives are a great way for teams to continuously improve the way of working. Getting workable actions out of a retrospective and getting them done helps teams to learn and improve.

To do agile retrospectives it’s important to understand what they are and why you would want to do them. This helps you to motivate team members to actively and openly take part in them. Many exercises exist for retrospective facilitators to design and perform a retrospective.

This blog post is based on Getting Value out of Agile Retrospectives, a pocket book by Luis Gonçalves and Ben Linders that contains many exercises that you can use to facilitate retrospectives, supported with the “what” and “why” of retrospectives, the business value and benefits that they can bring you, and advice for introducing and improving retrospectives.

What is an Agile Retrospective?

The agile manifesto proposes that a “team reflects on how to become more effective”. Teams use agile retrospectives to inspect and adapt their way of working.

A retrospective is normally held at the end of each iteration, but teams can do it as often as needed. It focuses on the team and the processes used to deliver software. The goal of retrospectives is helping teams to improve their way of working.

All team members attend the retrospective meeting where they “inspect” how the iteration has gone and decide what to improve and how they want to “adapt” their way of working and behavior.

Typically a retrospective meeting starts by checking the status of the actions from the previous retrospective to see if they are finished, and to take action if they are not finished and still needed. The actions coming out of a retrospective are communicated and performed in the next iteration.

To ensure that actions from a retrospective are done they can for instance be added to the product backlog as user stories, brought into the planning game and put on the planning board so that they remain visible to the team.

Why Do We Do Retrospectives?

Organizations need to improve to stay in business and keep delivering value. Classical organizational improvement using (large) programs takes too long and is often inefficient and ineffective. We need to uncover better ways to improve and retrospectives can provide the solution. Many agile teams use retrospectives: to help them solve problems and improve themselves!

What makes retrospectives different from traditional improvement programs? It’s the benefits that teams can get from doing them. The team owns the agile retrospective. They can focus where they see the need to improve and solve those issues that hamper their progress. Agile retrospectives give the power to the team, where it belongs! When the team members feel empowered, there is more buy-in from the group to do the actions which leads to less resistance to the changes needed by the actions coming out of a retrospective.

Another benefit is that the team both agrees upon actions in a retrospective and carries them out. There is no handover, the team drives their own actions! They analyze what happened, define the actions, and team members do the follow up. They can involve the product owner and users in the improvement actions where needed, but the team remains in control of the actions. This way of having teams leading their own improvement journey is much more effective and also faster and cheaper than having actions handed over between the team and other people in the organization.

Retrospective Exercises

How can you do retrospective meeting that delivers business value? A valuable agile retrospective identifies the most important things that a team wants to work on to improve their process. But what is most important? It can be the biggest, most current impediment your team has. Maybe something is disrupting your team’s atmosphere and they can’t get a hold of it. Or it could be finding the reason why the current iteration failed, or why it was such a big success.

Teams differ, and also the things that teams deal with can be different in each iteration. That is why there is no single retrospective exercise that always gives the best results. Also the risk exists that teams get bored when they are always doing retrospectives in a similar way. A solution to this is to introduce variation using different retrospective exercises. So before starting a retrospective, you need to think about which exercises would be most suitable.

The retrospective facilitator (often the scrum master) should have a toolbox of possible retrospective exercises and be able to pick the most effective one given the situation at hand. Here are some examples of retrospective exercises:

  • An easy but powerful exercise is Asking Questions. There are many different questions that you can ask in retrospectives. The trick is to pick the ones that help the team gain insight into the main and urgent issues and identify improvement potential. Then, by asking more detailed questions, it allows the team to dive even deeper into the retrospective.
  • The Star Fish is a variant on the “What went well?, What did not go so well?, What can be improved?” exercise. The Star Fish retrospective use a circle with 5 areas to reflect on what activities the team should stop right away, what activities the team should continue with in a reduced role, what activities should be kept, what activities should play a bigger role in the future and what activities the team should start.
  • The Sail Boat is an exercise to remind the team of their goal the product they need to deliver, the risks they might face, what is slowing them down and most importantly, what helps them deliver great software. It uses a metaphor of a boat, rocks, clouds and islands.
  • The moods of team members are often affected by problems encountered while working together. Having team members state their feelings in a retrospective using the Happiness Index helps to identify possible improvements. This exercise uses a graphic representation of team members´ emotions.
  • If there are significant problems that a team wants to avoid in the future, you can use Five Times Why exercise. This exercise uses root cause analysis to get to the deeper causes of problems and to define actions that address them.
  • A Strengths-Based Retrospective visualizes the strengths that your team members and teams have using a solution-focused approach. It helps to explore ways to use strengths as a solution to the problems that teams are facing.
  • When you have an agile project with multiple teams, you can do a Retrospective of Retrospectives to improve collaboration between teams. This is an effective way to share learning’s across a project and to solve problems that a project is facing.

Our advice to retrospective facilitators is to learn many different retrospective exercises. The best way to learn them is by doing them. Practice an exercise, reflect how it went, learn, and improve yourself. Feel free to ask any question about retrospectives.

Valuable Agile Retrospectives

Agile retrospectives are a great way to continuously improve the way of working. We hope that this blog post helps you and your teams to conduct retrospectives effectively and efficiently to reflect upon your ways of working, and continuously improve them!

Our book Getting Value out of Agile Retrospectives and the related blog posts and articles mark the beginning of a journey. We are growing a small ecosystem to release more exercises in the future, How To´s, retrospectives´ advices and many other things. If you want to stay up to date, the best way is to subscribe to our Valuable Agile Retrospectives mailing list.

You can download the book Getting Value out of Retrospectives free of charge from:

About the Author 

Ben Linders is a Senior Consultant in Agile, Lean, Quality and Process Improvement, based in The Netherlands. As an advisor, coach and trainer, he helps organizations by deploying effective software development and management practices. He focuses on continuous improvement, collaboration and communication, and professional development, to deliver business value to customers. Ben is an active member of several networks on Agile, Lean and Quality, and a frequent speaker and writer. He is an editor for Agile at InfoQ and shares his experience in a bilingual blog (Dutch and English). You can also follow him on twitter at @BenLinders.

Posted in Agile Adoption, Agile Methodologies, Lean, Scrum Development, Scrum Methodology | Leave a comment

SAFe and Other Frameworks for Scaling Agile: A Case Study

The following is a guest post from Brad Swanson, VP and Sr. Agile Coach at agile42

Scaling agile is one of today’s top challenges for many. I hear it from our customers all of the time. When agile and non-agile worlds collide within an organization, time to market and software quality often suffer. There are a number of fans in favor of the Scaled Agile Framework® (SAFe™) as the solution. I want to point out that while SAFe is highly effective for some organizations, it may not be the solution that’s best for you — OR you may be going about it the wrong way.

To demonstrate my point, I’d like to share this case study…

Introduction

We recently worked with a leading cable TV company that faced long and challenging development cycles with software quality problems. Guided by a small team of coaches*, they successfully implemented the Scrum framework with SAFe to scale up to 150 people delivering their set-top box/DVR software and server-side systems to support the DVRs. The following challenges drove the need for change:

  • 12+ month release cycle; unable to respond to a rapidly changing marketplace
  • Missed delivery dates; schedule slippage
  • Quality problems due to late integration and 3 concurrent versions in development

Agile methods and SAFe reduced time-to-market for major releases from 12+ to only 4 months, the shortest practical timeframe, given the cost of deploying firmware to over 11 million DVRs nationwide. Releases changed to fixed-date; scope was managed and prioritized to ensure that all business capabilities were delivered on time, even though some low-priority features (‘bells and whistles’) were cut to meet the delivery date. Quality improved significantly as a result of earlier and more frequent integration testing, which is fundamental to the agile approach. SAFe was tailored to the organization’s unique needs after piloting elements of it on a smaller scale.

Here’s what we learned:

  • The Agile Release Train model is effective for coordinating efforts of multiple, tightly integrated teams toward a short-term delivery.
  • Many elements of SAFe can be eliminated or scaled back when teams are working on decoupled or only loosely integrated products, features, or components; the Program level in particular may be excessive.
  • SAFe is sometimes implemented in its entirety in a “big-bang” change. This is possible, but extremely challenging and risky. Our  recommendation is to implement elements of SAFe in pilot mode to address known pain points, empirically determining which elements work and how, rather than pushing unproven changes to large swaths of the organization.

Scaled Agile Framework overview

The Scaled Agile Framework web site thoroughly describes the SAFe model. SAFe defines three levels for scaling an Agile organization:

  1. Portfolio
  2. Program
  3. Team

At the portfolio level, Lean-Agile principles are applied to balance workload with delivery capacity and optimize value delivered, while aligning architectural efforts. At the Program level, product features are integrated and tested often by a System team. At the team level, multiple agile teams build and test small features within a single business domain or system component, and deliver running, tested features (user stories) on a set cadence (usually every 2 weeks) to the System team. SAFe prescribes fixed released dates with variable scope using the release train metaphor; if a feature misses the train (the date), it has to wait for the next release train.

Other frameworks for scaling agile methods are also useful in many contexts, including Disciplined Agile Development, Large Scale Scrum from Larman/Vodde, and Scrum of Scrums.

Managing change: evolution or revolution?

At agile42, we recommend an incremental and empirical approach to introducing agile practices at scale, rather than prescribing one particular framework to implement. Scaling lean-agile practices is a complex problem and every organization’s context is unique. Long-term success is more likely with an empirical and evolutionary approach, as described in agile42’s Enterprise Transition Framework™.

(1)                Assess challenges to identify specific needs for improvement

(2)                Pilot changes in a low-risk way

(3)                Empirically measure the results of the change

(4)                If the pilot succeeds, expand the practice more broadly

(5)                Repeat…

In the cable TV case study, agile practices were first piloted by 2 teams. We tried many of the SAFe practices throught the pilot efforts and used the lessons learned to guide the expansion of agile and SAFe.

 

Where the full SAFe framework was excessive

A different agile42 client, a financial institution, issued a corporate mandate to implement SAFe. In this case, teams did their best to implement all of SAFe in a “big-bang” rollout. It became clear after a few releases (4 months) that significant portions of SAFe were unnecessary, and even counter-productive in their context. Their 5 teams were each working on mostly independent applications, and there was no need for the overhead and coordination of a Program-level agile release train so they abandoned it, allowing teams to operate more independently. An evolutionary approach could have helped this organization learn what parts of SAFe were applicable in their context, in a less disruptive manner.

 

Reducing time to market

In our case study, the cable TV company changed their release cycles as shown in Figure 1.

figure 1

Figure 1 – Product development cycle before and after

The agile development cycle uses the release train concept from SAFe. Releases have a fixed date, and scope is selected — and adjusted if necessary — in order to meet the deadline. If a feature misses the train, it has to wait for the next train. By aggressively prioritizing scope throughout development, and frequently integrating and testing, this model ensures that a viable product with the most important features will be ready on the planned date.

Portfolio Planning

The R&D organization started with a list of over 150 requests for features (projects) from the business. Senior leadership formed a Product Council consisting of 10 Product Owners (product managers), each of whom was aligned with a particular business area, plus R&D Directors. The Product Owners each made a ‘sales pitch’ for the highest value projects/features in their own domain, and the Product Council stack-ranked all the requests that might fit into a 4-month development cycle based on ballpark estimates. Ranking was accomplished by first scoring each request on a number of criteria: importance to business stakeholders, alignment with strategic initiatives, and cost of delay (urgency). This objective scoring cut the number of ‘contenders’ down to a more manageable number, from which point the Council members used a multi-voting technique to arrive at a final ranking.

Agile team structure

See Figure 2 below for a description of team structure before and after. Before agile was introduced, most of the people worked in large teams organized around technology components: the DVR (client) component and several back-end server components. Most of the business features however, required both client and server.  As a result, there was no clear ownership of the end-to-end business value. In the agile model, most of the people were organized into smaller feature teams (purple in Figure 2 below), each one owning features across client and server for one area of the business. One component team on the server side remained focused on building a major new architectural service. To maintain design integrity across feature teams, virtual platform teams coordinated designs across all the feature teams, as shown by the dotted line boxes  in Figure 2.

At first, the management team thought it wouldn’t be possible to form small cross-functional feature teams because each one would require too many people across too many specialties. So they put the names of every person on a separate card and began moving them around, trying to form feature teams of 10 people maximum. The managers were surprised to find that could form feature teams with only few gaps in skill sets and a handful of specialists (such as DBAs) who would need to serve multiple agile teams. Some organizations have accomplished the same structure through self-organization: allowing all the team members to collectively choose teams, rather than having a few managers do it. This organization wasn’t quite ready to embrace that idea.

fig 2

 Figure 2: Team structure before and after

 

Release train (4-month) planning

Figure 3 below gives an overview of the release train timeline.

fig 3

 Figure 3: Overview of the release trains from portfolio planning to delivery

  • 4 weeks of portfolio planning
  • 2 weeks for each team’s independent release train planning
  • 1 day for all agile teams to build a combined plan for the release
  • 4 months for building and testing – using 2-week sprints/iterations

With the portfolio priorities clear and team structure decided, each new team spent about 2 weeks doing high-level release train planning. Each release train was a 4-month period culminating in an integrated delivery from all the agile teams. Each Product Owner decomposed high-level business requests (features or projects) into smaller pieces (called stories), and prioritized the stories. The newly formed teams independently estimated the scope they could deliver in 4 months and identified dependencies on other teams.

The entire R&D organization (about 120 people) gathered in one room for the 1-day release planning event, except for one team that joined remotely by video conference.

1-day release planning agenda:

  • VP of R&D shared the vision and goals for the upcoming 4-month release train
  • Marketplace of collaboration: Each of the 10 teams had a large, visible timeline of features they planned to deliver in 4 months. People circulated between teams to better understand synergies and negotiate dependencies. (See Figure 4)
  • Each team adjusted their plan to reflect newly discovered dependencies and adjusted scope
  • All agile teams combined their release plans into a single visible timeline covering the 4-month period. (See Figure 5)
  • A retrospective on the 1-day event: lessons learned to improve the next one.

fig 4

 

Figure 4: One team’s release plan on the wall; collaboration with other team members

fig 5
Figure 5: Combined release train plan for all 10 teams

Delivery Sprints

Each team worked in 2-week sprints (development iterations) throughout the 4-month release train.  The system test team integrated the work of all teams every sprint to test new features and run a regression test on the entire system. Some tests were automated but many required manual validation of video. The Product Owners from each meet met biweekly (once per sprint) to coordinate their work; additional team members participated when necessary. The final 2-week sprint was a ‘hardening sprint’ with all hands on deck to perform final regression testing.

Results

  • The release was delivered on time with 100% of planned business capabilities delivered and 95% of planned low-level features included.
  • Quality was higher than previous long-cycle releases: fewer total defects total and fewer severe defects were discovered post-release.
  • The 1-day release planning event was an overwhelming success. People really appreciated the opportunity to understand the big picture and quickly reach a common understanding of the goal and scope of the release.

Challenges:

  • Forming feature-oriented teams was initially viewed as impractical due to the large number of specialists required to build the perfect team. Through many rounds of name-swapping, we arrived at a set of teams that each was focused on a single business value stream and consisted mostly of full-time dedicated people. A small number of specialists spread their time between multiple teams to fill specific gaps.
  • Regression testing every 2 weeks was possible only because the organization had invested in test automation. Still, some testing was manual and incremental testing was a significant shift for the system testing team.
  • One of the feature teams struggled to integrated the client-side and server-side developers into a truly integrated team. They reporting structure and culture separated those two disciplines, and in practical terms they worked as 2 separate teams.

Conclusions

SAFe was an appropriate model for the cable TV company because multiple teams are all building a single integrated and complex product. Prior to adopting SAFe, the organization had already piloted Scrum on 2 teams with the help of experienced coaches, and learned how to make Scrum work in their context. This evolutionary approach to adopting Agile and SAFe was a critical factor in learning how to succeed in delivering on-schedule with high quality.

The experience of the financial institution, on the other hand, where  SAFe was mandated, demonstrates the risk of wholesale adoption of a prescriptive framework without first piloting changes on a smaller scale and measuring the results. The financial institution learned that much of SAFe was overkill in their context.

Key takeaways

  • The release train model is effective for coordinating efforts of multiple, tightly integrated teams toward a short-term delivery.
  • Many elements of SAFe can be eliminated or scaled back when teams are working on decoupled or only loosely integrated products, features, or components; the Program level in particular may be excessive.
  • SAFe is sometimes implemented in its entirety in a “big-bang” change. This is possible but extremely challenging and risky. Our  recommendation is to implement elements of SAFe in pilot mode, evolving as you learn which elements work and how, rather than pushing unproven changes to large swaths of the organization. The agile42 Enterprise Transition Framework™ takes the evolutionary approach.

*Many thanks to the team of coaches who joined me on this effort: Manny Segarra, Deanna Evans, and Ken McCorkell.

Posted in Agile Methodologies, Agile Teams, Enterprise Agile, Scaling Agile | 1 Comment