This Isn’t a Race!

Have you experienced problems with competition amongst team members/developers within a Sprint. A Sprint is a race, after all. Most people associate this term to mean a short dash, going as fast as you can, competing against a number of others. There’s a great new show called Silicon Valley (by Mike Judge of Beavis and Butthead fame) that shows this dysfunction on a Scrum team.

Silicon Valley Scrum Pic

http://youtu.be/oyVksFviJVE (Warning: funny, but slightly inappropriate in areas)

After watching this, ask yourself, are we truly a team trying to achieve a common goal, or are we still individuals competing amongst one another? How do we measure progress? How do we reward folks? How do we handle the type of dysfunctional behavior in the above video, and who does it? Is this is a reason to begin using the term Iteration instead of Sprint?

In my experience, I’ve not seen the competition quite so blatant amongst developers as in the aforementioned video. But I have seen it. And as a Scrum Master and an Agile Coach, I have pointed them back to the Agile Manifesto’s 12 Principles…

http://www.agilemanifesto.org/principles.html

The one that stands out, to this point is…

Working software is the primary measure of progress.

In other words, we’re not measuring lines of code written, or story points completed, or hours worked. We’re measuring working software completed, at the Team level. Did we, as a Team, meet our Sprint goal, and deliver something valuable to our customer through early and continuous delivery.

Velocity is another metric that gets misconstrued, in my experience. At the end of the day, velocity is a planning metric for the Team. We shouldn’t use it as a measure of speed compared to another team or another individual; i.e. I’m a great developer because I was able to complete 4 stories for a total of 20 story points in this 2 week Iteration. The guy sitting next to me only got 10 story points done. Therefore, as their logic goes, I’m twice as good a developer as him. And I should be compensated accordingly when it comes bonus time.

Yeah, but what if we have slackers on our team, and there’s really only one or two people doing a majority of the work? Well, there’s probably a reason for this behavior, actual or perceived. My advice is to dig in to the root cause. Clearly fodder for the Retrospective at the end of the Iteration (a.k.a. Sprint). Beyond that, it’s really up to the Team to resolve if they can. Escalate as necessary.

My initial assumption starts with the idea that we have self-motivated individuals on our Teams. And that it’s my job as a Scrum Master to provide them the environment and support they need to get the job done. If I can’t do that myself, I get help. Servant leadership.

What experiences have you had with intra-team competition?

Posted in Agile Adoption, Agile Management, Agile Teams, Scrum Methodology, Uncategorized | 2 Comments

Sutherland Answers Top Questions from AgileLIVE “Power of Scrum” Webinar

agile-and-scrum-webinarGuest post from Jeff Sutherland, co-creator of Scrum and CEO of Scrum Inc.

In case you missed it, earlier this month VersionOne broke record attendance (5,000 registrants) for our AgileLIVE webinar series. Jeff Sutherland keynoted the event with a focus on “doing twice the work in half the time” with agile and Scrum principles.

Jeff must have said something right because the attendee questions flooded in. Since we ran out of time to answer all of them on the live webinar, we asked him to answer the most common questions right here for you to learn and share. If you find these helpful, please download the full recording of AgileLIVE: “Getting to Done – The Power of Scrum.”

Q: Do we need some initial design done before we engage a developer?

A: The designer should be part of the team. How much design needs to be done should to be worked out in the team before coding begins? This question is similar to, “Do we need a tester before we can ship?” All people necessary to get to Done need to be on the team working as a team.

Designers struggle with this concept when they are not cross-functional and tend to work across teams. At Scrum Inc. we put a design expert on one team even if they have to help other teams.

Q: How is Story definition effectively managed? Is Story definition considered part of a Sprint?

Getting user stories or product backlog items in a ready state takes place during the previous sprint in product backlog refinement. The Team and ScrumMaster should expect to spend about 10% of their time working with the Product Owner to refine the stories for the coming sprint during the current sprint. We have tried to make this clear in the Scrum Guide at scrumguides.org.

Q: We know that Scrum can be applied outside of coding software. What generic term would we replace “Working Software” with in the Agile Manifesto for efforts that are not software development efforts? Working Deliverables?

Joe Justice leads our agile hardware practice. He uses this wording:

“The Agile Manifesto applies to all industries. When we read it and its 12 principles, and switch each mention of “software” with “customer visible value,” we have an elegant methodology that applies to all business.”

Q: We are applying agile and Scrum methodologies to marketing efforts (with adjustments for marketing). Have you ever worked with or witnessed agile in other areas beyond software? Do you think it works?

One of the driving motivations behind publishing my new book, “Scrum: the Art of Doing Twice the Work in Half the Time” was to show how effective Scrum could be in all industries. In fact 80% of the examples in the book are non-software related.

My company Scrum Inc. is a business services organization and we Scrum everything: marketing, finance, sales, and content creation. Many of the companies I work with use Scrum in marketing. Sometimes the marketing Scrums are better than the development Scrum teams.

Q: What are some of the approaches you recommend for getting to consistent story points, especially across teams?

Getting consistent story points across teams is not important. What you want to look at is acceleration across teams. Teams will estimate in ways that makes sense to each individual team.

However, Scrum Inc.’s Chief Product Owner Alex Brown has conducted a number of experiments. He found that dropping similar backlog items into different teams’ backlogs can give a Product Owner a pretty good idea of point variability between teams. He then estimates how long it will take to complete an epic that is being worked on across multiple agile and scrum teams.

Q: What is your view on LeSS (Larman and Vodde) and Scaled Agile Framework® (SAFe™) by Dean Leffingwell.

For non-agile organization’s looking to transform, LeSS and SAFe might be good places to start. However, these prescriptive scaling frameworks can eventually become a major impediment as the organization’s agility matures. LeSS is closer to Scrum principles. SAFe adds extra overhead.

We talk about the basic components of scaling in our Scrum@Scale online courses at scruminc.com. There we describe where SAFe and LeSS might be useful. We also point out that scaling agile needs to fit the organization and its goals. A company like Spotify would not use prescriptive frameworks. Large companies we work with that start with SAFe soon find they need to change the organization and eliminate waste, which moves them beyond SAFe. Dean Leffingwell points out that SAFe is a starting point.

Scrum is fractal and based on Object Oriented Architecture. It was designed to scale. In fact, the first scaled Scrum pre-dates the Agile Manifesto by many years. It was similar to the approach Spotify uses today.

Related links:

Product info – Scaling agile and scrum with VersionOne

Webinar recording – AgileLIVE: “Getting to Done – The Power of Scrum”

Blog post – SAFe and Other Frameworks for Scaling Agile

Blog post – What is the Prerequisite of Success When Scaling Agility?

 

 

Posted in Agile Adoption, Agile Benefits, Agile Development, Agile Marketing, Agile Teams, Scaling Agile, Scrum Development, Scrum Methodology | Leave a comment

‘Twas The Night Before Sprint Planning

daniel gullo ABC consultingWe hope you enjoy this holiday poem on Sprint Planning. It was an early holiday gift to the Agile Management Blog from Daniel Gullo, owner/principal of Apple Brook Consulting. Thanks, Daniel!

‘Twas the night before Sprint Planning, and all through the Team
Not a member was worried about the upcoming theme.

The Stories were refined and the Backlog was set;
Poker had been played without a single bet.
Appropriately sized and estimates all sound;
Acceptance Criteria to establish firm ground.

The ScrumMaster and Product Owner had just finished a call,
To talk about ordering and a potential Sprint Goal.

The Retro had happened several days prior;
The Scrum Team had discussed how to move the bar higher.
Agreements were revised and the Definition of Done
Included more testing and other such fun.

The stakeholders were eager to see the new stuff:
“The product has value!! Perhaps we have enough??”

In the last Sprint Review, the Team had shone bright,
A shippable increment, a product in its own right.
Wouldn’t be long ‘til the Team would release,
Causing the customers’ delight to increase.

The CEO and the VPs were finally content,
The decision to be agile had caused no lament.

Developers are happy in practicing their trade
Testers are ecstatic they are no longer blamed.
And everyone has a chance to really collaborate
Without worrying about the build being late.

As dawn approached and meeting was nigh,
The Team members were up on an adrenaline high;
Excited to move forward and full of new hints,
The wonder of Scrum and working in Sprints.

“Is agile right for me?” you may be wondering,
As your organization continues with delivery blundering.
If your culture is ready to be focused on learning,
Agile will help you return to positive earning.

Blessings-

Daniel Gullo
CSC, CST

Get more info on sprint planning within VersionOne.

Posted in Agile Adoption, Agile Benefits, Agile Teams, Agile Testing | 1 Comment

Secret Sauce of Running a Great Scrum Team

In this guest post by Jeff Sutherland, co-creator of Scrum and CEO of Scrum, Inc., you will learn five reasons why 49% of agile projects fail – and how you can avoid it.

jeff sutherlandMy book, “Scrum: The Art of Doing Twice the Work in Half the Time,” was published in October. Over the last six weeks, I’ve been touring the U.S. and Europe telling the story of all the influences that culminated in the creation of the first Scrum team over 20 years ago. No matter where I go, people ask me what the secret is to running a good Scrum. The secret sauce of running a great Scrum Team is Getting to Done!

Bad Agile

There is a lot of “bad agile” out there. According to Jim Johnson at The Standish Group, 49% of agile projects fail. Why? Because people don’t grasp the essence of what it means to be agile. It requires a fundamental shift in thinking. The second value of the Agile Manifesto is quite clear: Working software over comprehensive documentation. That means that at the end of each and every Sprint you have potentially shippable increments that work!

Working software is key because it is the catalyst for one of the most important aspects of the Scrum Framework: feedback. If you don’t have working software at the end of the sprint, stakeholders can’t use it during the Sprint Review and, as a result, can’t give the Product Owner and team the feedback that will allow the team to develop the product into the customer’s sweet spot.

The secret to working software is complete testing inside the Sprint. If your agile testing practices aren’t tip-top, your teams are probably struggling, your customers are probably frustrated, and you most likely don’t know when the product will ship.

Five Causes of Team Failures

1.  Poor definition of DONE
2.  Stories not READY
3.  Dysfunctional Leadership
4.  Technical Debt
5.  Ineffective coaching

A rigorous definition of Done includes working tested product at the end of the Sprint. Teams must work together to refine their definitions of Done. Product Owners have to stop accepting Stories that don’t meet these criteria.

Good definitions of Ready and Done are two levers that produce successful Sprints. Stories don’t magically become Ready; they need to be clarified and granulated. Acceptance tests need to be embedded. This takes time and attention from the Team.

A leadership team that sees the benefits of going agile, but hasn’t engaged enough to shift their mindset, is a recipe for disaster. Scrum works because it allows capable workers to self-organize and determine how best to accomplish their goals. If management maintains a command-and-control mindset, a Scrum implementation will fail.

In an agile context, managers become leaders. They are tasked with setting transcendent goals for the organization, supporting the teams and removing organizational impediments. They need to determine what Scrum metrics would best bring transparency to the processes so they can hold the Product Owners responsible for value delivery and ScrumMasters responsible for velocity.

Technical debt needs to be stopped in its tracks. The discipline of having clean code every day is essential, as is completing all testing within the Sprint. Then the historic technical debt can be reduced piece by piece.

When implementing an organizational change, companies are pretty good about educating their employees but they fail to provide them with support they need to succeed. The most successful implementations not only get their workers certified but also bring in outside agile training and consulting services help to launch the teams.

A team launch includes an expert coach who helps develop the first iteration of the Product Backlog, helps the teams define what it means for a story to be both ready and done, and leads them through all the Scrum ceremonies at least once. Ideally, the coach returns periodically to fine-tune the teams’ work and take them to the next level.

In Conclusion

Systematically focusing on remediating these issues will consistently produce high performing teams with 200% to 400% improvement in production.

Failure to focus on them will add yet another team to the 49% of teams that are “Bad Agile,” leading to unhappy customers, lost revenue, and lower stock prices.

For more information, grab the recording of my recent AgileLIVE webinar: “Getting to Done – The Power of Scrum.”

 

Posted in Agile Benefits, Agile Leadership, Agile Management, Agile Methodologies, Agile Teams, Agile Testing, Scrum Methodology | Leave a comment

Agile Teams Should Sprint, But in the Same Direction as Enterprise PPM Strategy

CA logo

 

Guest post by James Chan, director, technical presales at CA Technologies

James-Chan

Catch James Chan’s talk on AgileLIVE Wednesday, December 10, 2014: “Portfolio Strategy + Agile Execution: Coordinating, Not Competing.” Details at http://pm.versionone.com/AgileLIVE-2014-CA-PPM.

I think we can all agree that agile techniques have made their way into large enterprises. As agile adoption crosses the threshold into large enterprises, agile teams sometimes begin to struggle with determining the items of highest business value when delivering syndicated enterprise solutions.

Depending on which client the team interacts with, the definition of priority and business value can easily fluctuate. In large enterprises, product owners and agile teams need some way to connect to the bigger picture of enterprise strategy and ensure that enterprise goals are met, while being fiscally responsible to deliver on items that are being funded.

To add an additional level of complexity, enterprises may have pockets of agile work, as well as pockets of traditional work. Enterprises are rarely homogeneous. In many cases, enterprises run under a hybrid model, where the development and QA teams leverage agile techniques, but other teams such as the PMO, product management, sysops, enterprise architecture, user experience, and devops may use other techniques.

Because enterprises live in this space, there needs to be a way for those in charge of strategy to perform their market-sensing activities to develop, define, select, and fund an enterprise’s strategy. This strategy then needs to be communicated to those responsible for product delivery to align them with strategy and identity problems they can solve, as well as opportunities they want to exploit. Once these items of highest business value are defined and prioritized, that vision can then be communicated to the execution teams to realize the vision in a manner that is most effective for them and the enterprise.

To ensure that everyone in the enterprise is rowing in the same direction, and to fully realize the benefits of agility, enterprises need to take a look at the bigger picture. Many are looking at agile execution techniques as part of a larger enterprise ecosystem through project and portfolio management solutions. Enterprise PPM (portfolio management) helps with alignment, enabling enterprises to couple speed with thoughtful planning. Project and portfolio management solutions help portfolio managers define the enterprise’s trajectory needs and balance initiatives that support the strategy with financial capital and human skills. They can also collaborate closely with product management to define the problems they should solve as well as the opportunities they want to exploit in support of the enterprise’s vision.

Finally, that collaborative roadmap needs to be the guiding force for agile execution teams to ensure that as they are sprinting, they are sprinting in the same direction. If teams just focus on the smallest unit of work, which is a user story, they can quickly lose sight of value and get lost in the trees. So in order to ensure that teams drive toward overall delivered business value, enterprise strategy and trajectory need to be taken into account.

So how do you do this? A good place to start is by checking out the CA PPM (Project and Portfolio Management) integrated solution with VersionOne. This unified enterprise PPM solution gives you a clear picture of all projects from the top down, from high-level feature planning to work item assignment. By combining strategic, financial portfolio management capabilities with ALM software, you can get your agile teams sprinting in the same direction as your enterprise strategy – so business value gets delivered faster and the transition to enterprise agile is simpler.

James will present on this topic during VersionOne’s AgileLIVE™ webinar on Wednesday, December 10, 2014 from Noon to 1 p.m. EDT. Details and registration:

AgileLIVE: CA PPM and VersionOne webinar:

“Portfolio Strategy + Agile Execution:  Coordinating, Not Competing”
December 10, 12-1 p.m. EDT

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

Getting The Most Out of Your Agile Testing

Guest post by Kevin Dunne, product specialist for QASymphony

Getting the Most Out of Your Agile Testing

Testing—even in agile environments—is almost always constrained. Testers and developers may feel beholden to legacy software investments or stuck with status quo methodologies. Or, they’re just too busy testing to re-evaluate their processes and tools. Continuous attention to technical excellence and good design must encompass the testing function. And when it does, you can expect a higher-quality product and faster timeframes.

Blurring the Lines

Picture a manufacturing plant with cells of specialized workers segmented by skills and job output. When one group of workers in a cell completes a segment of work, the product moves to the next group of workers in an iterative process. In many development teams, developing and testing cycles occur in a similar fashion. Developers write code, and once it’s complete, the testers test. Agile replaces this outmoded factory model with integrated development cycles and collaboration. This means testers and developers are side by side, creating a lot of beneficial scenarios, including:

  • Early clarification of software expectations,
  • Shortened feedback loops, and
  • Streamlined communication

When testers are involved in the sprint, it helps ensure that test design is integrated very early in the process. The testers provide their input and expertise as to what can be completed realistically and delivered across sprints. And they are usually in tune with the customer, able to distinguish between design and intended use of an application from the way an end user will actually interact with it.

Integrating the testing function early on helps product owners clarify acceptance criteria and identify risks. Consider giving testers direct access to the customer to expose them to the customer’s desires for functionality. Then testers can immediately begin to translate customer needs into testable user stories. The “tester” mentality can help the team discern between reasonable and unreasonable expectations, and may give some indication of how delivery of expectations will be measured.

Test Early and Test Often

Many teams start the development process by prototyping and wire-framing to create a visual representation of content. When you enter all your requirements into an agile testing platform once your wireframes are complete, it is possible to show the developers what you’re trying to create—and show the tester what they need to validate—almost simultaneously. The testers utilize requirements for traceability, creating a test plan for each one. Developers and testers work on requirements and functional test plans in tandem, instead of tacking testing on at the end. Plus, integrated testing helps identify bugs early so developers can fix them fast. Instead of waiting until the code is developed to figure out if the acceptance criteria is met, and scrambling to fix the bugs before the product has to ship, development and testing occur concurrently on agile teams. When you can perform quality assurance in line with development, you will achieve high quality and high velocity.

Always Be Testing

A major initiative for most development teams is to reduce overall testing cycle time. Embedded testers can help teams shorten feedback loops—as less time passes between when a developer writes the code, the code is executed, and information is provided about how the code behaves.

Testers ensure that regression testing is built into the development process. Then as soon as code is loaded into the build, it can be tested. The longer it takes to identify code that doesn’t function properly, the more work product must be unraveled to find the source of the bug. Finding and fixing bugs early helped eliminate duplication and wasted man hours.

If you have access to a central dashboard, try to make real-time results and stats available to everyone on the team to “see as they go.” At any time, developers, testers and clients have visibility into what is happening throughout the process, fostering an inclusive problem-solving culture.

A Better Agile Testing Approach

Good design and technical excellence also apply to testing. Applying agile principles to testing, and incorporating testing into the agile environment means:

  • Development times are shorter
  • There is less process/documentation and more collaboration/interaction
  • All development team members, not just testers, are responsible for quality

If your testing approach and technology are not allowing you to provide intelligent, analytical, real-time feedback to development, are you truly getting the benefits of agile you could be?

About Kevin

Kevin Dunne is a product specialist for QASymphony, striving to ensure the continued success of existing and prospective members of the qTest community. Having acted as a tester in his previous jobs, Kevin enjoys interacting with customers on a daily basis to keep current on the latest trends and tools in the testing world. He is always eager to hear what others think about the industry – feel free to drop him a line at kevindunne@qasymphony.com.

Read more on agile test management

 

Posted in Agile Benefits, Agile Leadership, Agile Management, Agile Testing, Iterative Development | Leave a comment

5 Steps to Cultivating an Agile Culture

We’ve all heard the maxim change is difficult.  The reasons that change is hard are far too numerous to discuss in a single blog posting.  My intent here is to specifically focus on organizational agile transformations and the difficulty of changing culture.  Additionally, I want to leave you with some hope.  While it is difficult, it is not impossible.  There are steps that you can take as an individual that can help the organization as a whole move in the right direction.

The 2013 VersionOne State of Agile Survey indicates the top three reasons cited by practitioners for adopting agile within their organizations include accelerated time to market, the ability to more easily manage changing priorities, and to better align IT and the business, respectively.  These are desired results.  Unfortunately, viewing agile as a methodology alone will only minimally achieve these results, if at all.  The same survey cited the primary barrier to agile adoption as being the inability to change organizational culture.

Many adoptions focus primarily on providing training for individuals and teams.  Training is certainly crucial; unfortunately, many initiatives stop with training.  This is insufficient to sustain the change effort’s momentum.  It’s perplexing to me that organizations expect a shift in results with training alone?  It’s unrealistic.  Even when training is provided the attendees are thrust back into an environment that does not support new experiences that validate a new way of doing things.  The pyramid in the illustration below helps to visually explain why.

Change Pyramid

Individual Change Pyramid

First, I have to give credit for this illustration to Heather Hassebroek.  I met Heather only briefly at an agile conference, where we sat next to each other and started a discussion about why we think change is so difficult.  I think the pyramid succinctly demonstrates what’s occurring.  She jotted it down and I asked her if I could use it.  She graciously said yes.  Thank you Heather!

Our experiences lie at the base of the pyramid.  These experiences create and reinforce our beliefs and values, which drives our actions and behaviors.  The actions and behaviors produce results—both good and bad.  Therefore, one of the keys to transformation efforts is that it has to be rooted in individual experiences that breathe life into the new way of doing things.

For example, let’s consider the agile principle that states the primary measure of progress is working software.  To realize this principle we must first provide experiences that reinforce new values.  I have worked with teams that have attended training and seem to understand the principles of The Agile Manifesto very well.  The mindset just seems to make sense to them.  Yet, when returning to the day-do-day routine of their projects they fail to have stakeholders attend sprint reviews and are required to provide weekly project status reports including percent complete and red, amber, green stoplight indicators.  The team’s collective experience is that working software isn’t really valued as much as a status report.  This repeated shared experience leads to apathy and stalled transformations.  Alas, the team and organization continues to slumber under the status quo.

Here are 5 new experiences to consider if you want to foster an agile culture.  The list isn’t exhaustive, of course, but all of these are steps to consider if you want to reinforce new values and drive behavior change leading to positive results.

  1. Expect working software to be demonstrated at the end of a sprint.  If it can’t be demonstrated, it’s not done.
  2. If you need something from someone—call them!  Better yet, if you are co-located walk over to them and have a conversation and engage them in collaboration.
  3. If you’re a manager or executive, form stable teams.  If you do not understand the long-term competitive advantage of a high-performing stable team, you have much to learn about agile organizations.
  4. Be open about your failures at all levels (individual, departmental, managerial, etc.).  This has to start with you!  Don’t expect everyone to be open first.  You must demonstrate this behavior.  But consider this in a positive light.  Also be open about what you learned as a result of the failure.  Over time, this will help foster a learning culture.  Consider a team-level sprint or release award for the failure that led to the most learning.
  5. Experiment with pairing for 5 days.  I’m not simply referring to pair programming.  Try pairing in daily activities.  You may be surprised at the results.  If not, it’s only been for 5 days.  But give it at least that much time.  If it works you might even consider rotating pairs every week to help drive learning and building relationships.
Posted in Agile Adoption, Agile Leadership, Agile Management, Agile Project Management, Enterprise Agile | Leave a comment

Avoid Failure to Launch: Kick-Start Your Next Initiative

Guest post from two Davisbase consultants:  Adam Mattis and Leslie Morse

The Challenge

It’s a great day:  you wake up, the sun is shining, there is no traffic on the way to work, and when you get to the office… there it is. A shiny, new, fully sanctioned project. It’s GO TIME!

Easy there, killer. Before you dive in head first, let’s take a step back and get our proverbial ducks in a row.

All too often with agile-run initiatives or projects, we skip the foundational efforts that set the team up for success. In business environments where teams are constantly challenged to do more, faster, and with less, these foundational efforts are often overlooked. However, this quick-to-launch mentality ends up costing us much more, further on down the line.

What are these foundational efforts that we speak of? Let’s take a step back to bootcamp and remember the importance of:

  • Product Vision
  • Product Roadmap
  • User Roles
  • Initial Backlog Population
  • The Architectural and UX Runway

Three Preconditions for Starting Work

No one embarks on a new effort, initiative, project, or body of work with the intent to fail. However, agile development is often used as an excuse to make it up as you go along. Let’s frame up the goal of foundational work for agile workstreams by creating a user story.

user story table

 

1.  Business Readiness:  The degree to which business stakeholders are in alignment on what the vision is, who it is intended to benefit, and how much money should be investing in realizing the value.

2.  Architectural Readiness:  Ensuring that key IT stakeholders understand the vision and target scope for the effort as well as the definition of a high-level architectural approach to delivering value.

3.  Team Readiness:  Critical collaboration activities and workshops necessary to prepare the team for an incremental delivery cadence.

BUSINESS READINESS

The business defines the ‘what’ for an agile team; therefore, readiness on behalf of the business is of paramount importance before engaging the technology group. But what does business readiness look like?

Business Case: Defining the Need

The business case provides justification for funding a new initiative. Depending on your organization, this could be something as simple as an elevator pitch, or a much more detailed document outlining market opportunities, value propositions, return structures, etc.

Regardless of the level of detailed that is needed, having a clearly documented business case helps build a shared understanding of value among executives, sponsors, and key stakeholders. Continued support from these individuals is as key to the product launch as is the technical solution.  See Figure 1 for an example of the Elevator Pitch Structure.

FIGURE 1: Elevator Pitch Structure

figure 1

Product Vision

With the business case crafted, the next task is to develop a cornerstone for the team to focus on. This cornerstone, or product vision, serves as the high-level focus from which every epic, every feature, and every user story is created. All work done by the agile team should be focused on satisfying the product vision.

The vision should be comprised of the product name, a value statement, and a few key features that differentiate the product. The vision may also outline some basic technical requirements such as OS compatibility or platform such as “web-based.”

FIGURE 2 – Design the Box

figure 2

 

While it is important for the product owner and key stakeholders to understand and align on the vision when preparing to kick-start the initiative, keep in mind that it will be necessary to have a vision workshop with the cross-functional agile team in order to ensure a shared understanding of the product they are building. Once created, the product vision should be posted in a common team area to serve as an information radiator. The vision will help keep the team focused throughout the work cycle.

Product Roadmap

The product roadmap helps link the product vision to the work which agile teams do every day. The roadmap is not intended to be a commitment or project plan, but simply a guide that the agile team uses to plan their work during release planning sessions.

Without a roadmap, teams are left without a clear strategic vision. It is a common misconception that agile teams do not strategize. The reality is that agile teams are highly strategic and nimble enough to shift focus with rapidly changing market conditions.

FIGURE 3 – Product Roadmap

roadmap

 

The roadmap focuses on high-level themes, epics, or features – and, like the backlog, remains fluid throughout the course of the initiative. To be effective, the artifact should be highly visible and referred to often. As market conditions and priorities change, so should the roadmap and other downstream artifacts. Again, aligning on the roadmap before engaging the agile team is critical in order to avoid swirl and confusion when getting the team started. It is important to ensure that business stakeholders understand that the roadmap will most certainly evolve as the team begins work.

User Roles

With the ‘what’ defined in the business case, product vision, and product roadmap, it is now time to consider the ‘who.’ The definition of user roles seems like a fairly straightforward task, but once the discussion begins, teams are often surprised at how difficult the task can be.

Consider Facebook. On first thought it may seem simple: New User, Existing User, Administrator. Not so fast. Really think about all of the different interactions that take place on Facebook.

New User Existing User Business User Group Administrator
Advertiser Photo Poster Marketplace User Under 13

And that’s not even scratching the surface!

Now consider any system within your organization and imagine how challenging it would be to identify all of the different paths and user types within the system. Consider the importance of evaluating the individual needs of each of these users in creating a solution.

Remember, one of the key benefits of an agile culture is the delivery of high-quality, customer-focused software. If the team is not sure who they are solutioning for, it is likely that the product will not sufficiently satisfy the needs of anyone.

Baseline User Stories & The Backlog

With the product and users now defined, it is time to elicit basic needs from our business partners. Remember, the business product owner (BPO) is the tip-of-the-spear for all things business. The BPO serves as the single voice for the customer, product management, sales, marketing, legal, finance, and all of the other organizations that make up the business function. The BPO and supporting team need to elicit baseline user stories from each of these groups and place them on the backlog for prioritization.

As the program progresses, the BPO will be accountable for making sure any inputs from the business team are ready for the agile  team at the appropriate time. A few examples of these items may include legally approved verbiage, approved graphics from the marketing team, and any special promotional offers from the sales team. The BPO, with full control over the prioritization of the backlog, must maintain awareness of upcoming user stories and their dependency of these inputs.

ARCHITECTURAL READINESS

Now that we understand the ‘what,’ it is time to engage the technology group! HOLD ON… let’s tap those brakes! You’re only partially right. With the ‘what’ defined, we still have not begun to explore the solution. To begin framing up the ‘how,’ we need to engage the solutions architect.

Developing Shared Understanding

The solutions architect is in a unique position to begin bridging the gap between business need and technology execution. This individual has a broad view of all technology groups, infrastructure types, and data locations. In bringing the architect in early, the business will be able to get an accurate gauge of the technical feasibility of their ask, as well as the level of effort involved to deliver.

Identify IT Impacts

Once the feasibility study is complete, the solutions architect will start to map out the solution. This sketch will include the identification of new infrastructure, data flow mapping, and systems impacts. With this analysis complete, leaders can determine the right skill sets and organizational units that need to be involved in forming the agile team(s) who will work on the initiative.

TEAM READINESS

Let’s assume you’ve followed a good plan for initiating this new body of work. Your product owner is firing on all cylinders, business stakeholders are in alignment and engaged, the architects have a vision for the solution needed to deliver value, and the cross-functional set of agile team members are locked and loaded.  Please, please, please — don’t make the assumption that those folks are clairvoyant and have a shared understanding of what the organization is looking to achieve!

Agile teams need to practice the full Five Levels of Agile Planning [See Figure 4]. It doesn’t mean the product owner and business stakeholders do Levels 1-3 and the team only engages in Levels 4-5.  The entire agile team plus key stakeholders need to collaborate in order to prepare for the first sprint planning event. Highly effective agile teams engage in Levels 1-3 of planning during a timeboxed period often called Sprint Zero. When well-facilitated, it could take only a week, but spending more than four weeks on these activities would likely lead to analysis paralysis. Key preconditions, activities, and outcomes of Sprint Zero are outlined in Figure 5.

FIGURE 4 – Five Levels of Agile Planning

figure 4

 

FIGURE 5 – Sprint Zero Summary

figure 5

Start Small & Improve Incrementally

Feeling overwhelmed?  If you’ve got a gap in your pre-planning processes or you’re currently feeling the pain associated with a lack of readiness in one of these three areas, consider one of these three techniques in order to improve. After that, make a backlog of all of the opportunities to improve your pre-planning processes, prioritize the list, and affect change incrementally over time.

1.  The Stakeholder Engagement Cadence

Product owners are intended to be the single source of truth around ‘what’ the agile team needs to deliver. In order to effectively do this, product owners need to fully understand their stakeholders and proactively engage them so that priorities and acceptance criteria are the best quality possible.Figure 6 outlines a framework for a stakeholder engagement cadence where stakeholders are classified into one of three groupings (Advisors, Supporters, or Sponsors) and then, based on the classification, are brought together once a month, twice a month, or weekly, based on their level of involvement in the workstream. To learn more about this technique, check out Proactive Stakeholder Engagement, a post on Davisbase’s #BecomingAgile blog.

FIGURE 6 – Stakeholder Engagement Cadence

figure 6

 

2.  The Backlog Refinement Cadence
It is essential that teams keep a product backlog deep enough to sustain incremental delivery. While pure Scrum doesn’t call for teams maintaining a runway of “ready” stories or a projection of the backlog items they will be completing in which sprint, in practice – it is a useful planning approach for keeping flow within the system and aligning the dependencies and coordination points that often exist within organizations of scale and complexity. Figure 7 outlines a backlog refinement approach that creates focus for agile teams and helps build the discipline to keep one sprint’s worth of stories in a “ready” state, as well as get the details and specifications just enough in advance of the sprint where they will commit to the work.  When paired with the Stakeholder Engagement Cadence, this information radiator can also be useful for creating context on topics for collaboration. To learn more about the cadence for backlog refinement, check out the #BecomingAgile Webinar recording Strategies for Grooming Your Backlog.

FIGURE 7 – Refinement Cadence

figure 7

 

3.  The Architectural Feedback Loop

In a similar manner to how feedback is generated often in software demonstrations, it is equally as important for feedback to be passed on the to architect. On an agile team, the solutions architect is working six to eight weeks ahead of the development team laying down the architectural runway. If the development team finds that some elements of the architecture are either missing or not working, it is important to pass that information along to the architect on a regular basis in order to correct the issues in upcoming iterations.

As a result of this feedback loop, many technical and architectural user stories will begin to appear on the backlog. These elements can appear either on a product backlog in the case of tactical changes, or as the Scaled Agile Framework® (SAFe™) tells us, enterprise changes may appear on the program backlog.

FIGURE 8 – Architectural Epics

figure 8

Image courtesy of ScaledAgileFramework.com, 2014

 

 

Please comment on this post and keep the conversation going. We’re constantly looking for better ways of doing things and get excited by helping others with #BecomingAgile. Learn more by checking out these additional resources:

About the Authors

Adam Mattis and Leslie Morse are colleagues at Davisbase Consulting and, combined, have over 29 years of experience delivering value with software and information systems.

Adam is a program manager by trade residing in Nashville, TN. He spends most of his time working with new teams adopting agile practices. You can reach him at adam.mattis@davisbase.com or on Twitter @AgitatedAgilist.

Leslie is a business analyst by trade and resides in Columbia, SC. Most often she engages with organizations initiating agile transformations. You can reach her at leslie.morse@davisbase.com or on Twitter @lesliejdotnet.

Posted in Agile Adoption, Agile Leadership, Agile Management, Agile Teams, Enterprise Agile | 1 Comment

My Journey From Waterfall to Agile (and Back Again)

2007 – I had been working for several years as a traditional Project & Program Manager in the .com division of a Fortune 500 company. There was a constant cloud over my head. I didn’t really enjoy my work and had been soul searching for some time. I had been exploring and reading a lot about better ways to get work done, and came across this thing called Scrum. So I signed up for a CSM class, took it, was enlightened, and excitedly told my Director all about it. He gave me the green light to try it out on a small project or two, which I did. Somewhat surprisingly, these two projects were wildly successful. The productivity was more than triple the traditional Waterfall projects, the number of defects introduced was almost zero, our customers loved the quick feedback and the ability to change their minds whenever, and the buzz was that this was actually something fun to be a part of.

I was quickly named as the Lead Scrum Master, Coach, and Trainer for all things Agile, as I was the only one who knew anything about this stuff at the time. Others started inquiring about getting on one of these Scrum teams, how they could get training, how to get started, rooms, projectors, supplies, tools, etc.. I recruited some help, and we made incremental progress, getting more and more traction as we went along. It was very cool to be part of something like this. That’s not to say everything was perfect; it wasn’t. Our PMO still managed scope poorly, jamming too much work into a small pipe. Alignment at the Program and Portfolio levels wasn’t really there yet. Not everyone wanted to be part of a Scrum team, which we just kinda assumed they would. The culture held us back in certain areas. Not all the Management level was on the same page. We didn’t have any budget for external training, which is why they used me; I was ‘free’. But at the end of the day, enough folks were convinced this was something that was valuable that we expanded the initiative. 

2011 – I made the decision to leave the big company I had been working for to become an Agile Consultant at a small Midwest consulting firm in their Agile practice. It was an exciting time for me personally. I thought I’d be able to work with different clients, and help them do the same thing I did in my previous experiences. The opportunity for growth appeared to be huge. But as time went on, the work turned out to be intermittent at best, and we were struggling to gain any new business. Building up an Agile practice is not only hard work, but takes time, money and patience. The hard work part of the equation we had, but the rest was pretty limited. Once my 6 month Agile consulting engagement with our one and only customer was completed, I found myself in a bit of a pinch. We didn’t have another client for our Agile consulting services, and in order to stay on with the firm, I had to take whatever came my way. In this case it was a traditional Project Manager position with an insurance company. And yes, they utilized the Waterfall method of getting work done. The fact that I had a PMP after my name, and several years of good experience qualified me for the interview, which I passed. I needed the work, and so did my firm. The hourly rate was good, so I took it. I would soon come to find out what a nightmare I was in for.

It had been years since I last managed a Waterfall project, and those memories were less than fond. So I brushed up on my MS Project skills, dusted off the old PMBOK, reviewed the organization’s procedural guide for project management, and talked with some of the other PM’s at this new organization I’d be working with. None of them seemed too thrilled with their jobs, which was a red flag that I chose to consciously overlook. 

First week at the new gig was fine. Pleasantries, meeting the players, getting comfortable, reading procedural manuals, software downloaded, all that stuff you do the first few days. Then I got assigned as the Project Manager for three projects (one new and two in-flight). I was gung-ho and ready to show them what a great Project Manager they just hired. I was expected to manage the schedule, cost, and resources, which were all fixed. I would soon come to find out that this was not the case, but not in the way you might think. Managers would intermittently pull resources from in-flight projects to work on other higher priority projects or bug fixes, with the same expectations of us finishing the contracted scope and time deadlines for the projects. Of course, the beautifully constructed Gannt charts went down the toilet. I spent way too much time fighting for resources, adjusting the schedule, dealing with a multitude of dependencies, and discovering issues and impediments much too late. As each project team member was working on an average of 4 projects simultaneously, context switching was through the roof. The ‘throw it over the wall’ mentality was well established. There was a rush to get tasks completed on one project and move on to the next project. Back and forth, ad infinitum. Waste, frustration and technical debt; a vicious and unhealthy cycle that just dug deeper holes. I was also the person in between the customer and the team, and as such, was required to know everything, all the time, and communicate it all to everyone at least once a week in a high stakes status meeting where key team members would often either not show up at all, respond to emails on their phones if they did, and the internal customer would freak out about dates, scope, cost and risks. They didn’t want to hear about reality. Needless to say, those status meetings were hell. I was constantly on the hot seat, folks waited to be told what to do and when to do it, and when things fell down, the finger was squarely pointed at me, the Project Manager. This was not natural and it wasn’t working. The concept of a true Team was missing. It seemed that folks didn’t care about one another or the success or failure of the projects. I talked with a couple of my peers about their experiences, and while they recognized the same situation privately, they were not willing to call things out publicly. I presume this was based in fear. That cloud sitting over my head had returned. I knew the situation wasn’t sustainable, but I kept on for another couple of months anyway. It got to the point where my mental health was worth more than a paycheck, so I respectfully resigned. But just before I did, I had a chat with the Director of the Project Management Office. I talked with him about Scrum, and all the ways it could change things for the better, even in a regulated environment with hard completion dates. I explained it would be a big effort to transition to Agile. And that it wouldn’t happen overnight. That it would require investment. But over the long term, it was the smart thing to do and absolutely necessary to remain competitive. He listened, but wasn’t interested at the time. Too much critical stuff in flight to introduce such a change at the moment. Maybe later, he said. So that was it. At least I had tried. 

2012 – Happy ending to this story… I soon landed an Agile Coaching gig with a larger consulting firm on the east coast, shortly after the aforementioned Waterfall debacle. The client was open to new ideas and eager to transform their organization to Agile/Scrum/Lean/XP practices. We made a lot of headway by investing in people, teams, training, Agile Business and Technical Coaches, various tools, and open collaborative spaces. Upper and middle management created a culture of trust and transparency, and became true servant leaders to the teams. The business side began working closely with the technical side. No more throwing stuff over the wall and moving on to something else. We would succeed or fail as a team, not as individuals. Huge changes in a short period of time, yielding huge gains in productivity, efficiency, and quality. And most importantly, we gave the customer what they needed, not what they asked for 9 months ago. Customer involvement throughout was one of the key factors of this success.

During my tenure as an Agile Coach at the aforementioned consulting firm, we chose VersionOne as our ALM tool.  A VersionOne Coach and Product Consultant came in and helped us to configure the tool to fit the client’s organizational structure, showed us how to administer it, and trained a large group of IT and business folks on how to use it over the course of about two weeks. I got to know this VersionOne dude. We worked together on a few issues, and kept in touch. Soon there was an opening for an Agile Coach at VersionOne, and the rest, as they say, is history. I’ve been an Agile Coach & Product Consultant with VersionOne for about a year and a half now. The access and influence I’m afforded in helping organizations moving the Agile needle is amazing. It’d be hard to find this kind of opportunity with any other company. At the end of the day, I like helping people. And in my current role, it happens to be a perfect fit.

Posted in Agile Adoption, Agile Benefits, Agile Management, Agile Project Management, Scrum Methodology | Leave a comment

Enforced Workflow is inherently NOT Agile

balancing actOne of the ironies of being a technologist in the Agile world is that while we love our tools and toys, we also know that some things should be done by hand.  One of my jobs as a consultant at VersionOne is to help people understand what the tool will and won’t do.  Needless to say, I believe wholeheartedly that the tool does all that it should, and is a fantastic tool for understanding where we are as a team, and where we intend to go.  Its a very interesting balancing act, and I have always been impressed, especially when I was a customer, at how well the product management team performs this act.

 

I am often asked “when will you automate the workflow for a [epic/story/task/test]”?  My answer has been the same for quite some time now:  “hopefully never”.  This gets me some interesting responses, mostly disbelief.  The fact that the workflows are not predefined is not a missing feature, but a fundamental understanding of a basic fact.  Automated workflows are inherently not Agile.

Let’s start with the most glaring evidence of this statement.  The Agile Manifesto’s very Face-to-face-marketingfirst identified value is Individuals and Interactions over Processes and Tools.  Tools are valuable when they enable interactions between individuals.  When they start to replace those interactions, we are hurting ourselves.  Agile is about being able to be quick on our feet and embrace change, even late in development.  Having a tool enforce what should happen next slows that down.  Let the tool represent what is going on, not try to decide what is going on.

needless complexityThe next challenge is the fact that Agile teams understand the pitfalls of Big Design Up Front.  If  we acknowledge that trying to create an entire design and architecture up front is a waste of time and energy, why don’t we acknowledge the same for designing a process up front?  There are just too many different states that a story, etc. can be in during development to be able to predict the flow.  Any attempt to do so is taking energy away from our primary purpose, which is providing value to our customers.  Obviously we will have some agreements of general ideas, like Test comes first, and a story isn’t accepted until all of the tests pass, but we don’t need to automate that.

Lastly, let’s remember the main difference between Agile planning ideas and traditional planning ideas.  The idea around Agile processes’ planning is to reflect and react to reality.  VersionOne provides many ways to do this, my favorite being Team Rooms.  I want a wall sized monitor where I can project my Team Room on the wall in my workshop, providing me with a giant informed work-space.  Traditional processes try to bend reality to some arbitrarily decided workflow.  And guess what? Whenever there is a battle between our planned workflow and reality, reality will always win.

Posted in Agile Adoption, Agile Benefits, Agile Coaching, Agile Development, Agile Leadership, Agile Management, Agile Methodologies, Agile Portfolio Management, Agile Project Management, Agile Software, Agile Teams, Agile Tools, Distributed Agile, Enterprise Agile, Scaling Agile, Scrum Development, Scrum Methodology, Scrum Software, Scrum Tools, Uncategorized | 13 Comments