‘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 | Leave a 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 | Leave a 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 | 5 Comments

The Three People Who Need to ‘Just Say No’

Guest post by Scott Dunn, Rocket Nine Solutions

“We have too many things going on!” I hear this often from developers, product owners, even management. The problem is that we might be enabling this problem unknowingly (that does not, by the way, go away by itself). Depending on your role, I have three ideas for three different people: (1) the team, (2) managers and the PMO, and (3) the ScrumMaster.

At the team level, this complaint of too m­any projects or initiatives is very common. When I was a manager, my people would come up to me and say, “Jim in Marketing thinks I should be working on his request; Leonard just told me his changes were needed yesterday; and yet, we’re not even halfway done with Scotty’s list. Can you please tell me what’s the priority??”

Now that we’re doing Scrum, the priority is clear, right? There’s only one stack-ranked list from which to work. That gives us clarity, focus, limited work in progress, short feedback loops with everyone, and an increment of done-done potentially shippable software. Hallelujah!

Only, this is often not happening. No single list for a person, no limit on the work, no singing Hallelujah. The majority of companies and teams I’ve worked with miss out on this incredible win because they break a fundamental principle of Scrum… The team members are shared, or maxtrixed, with other teams or projects.

When stakeholders or management come to the product owner with a new request, the response from the product owner should be, “Let’s talk about where it fits in the backlog. Thanks; I’ll see where goes,” or perhaps, “Please tell me where it goes.”

Instead, these requests sometimes go to management or the PMO, and the manager or program manager says, “Okay, I’ll grab some people and get right on it.” But they’re grabbing people who are on dedicated Scrum teams. “Oh, that’s right – we’re doing Scrum. Okay, I’ll grab some people and form a new Scrum team and get right on it.”

And we’re back to people asking what’s priority, because “Jim thinks his team needs me about 75%, Leonard just told me their team needs me 100%, but my current team isn’t even halfway done with Scotty’s list. Can you please tell me what’s the priority??”

This matrixing is costing us not only in frustration at the team level. It’s costing us real dollars. According to a recent post on Inc.com, research shows the cost estimated at $450 billion dollars a year globally. How? A 40% drop in productivity, 50% longer to complete a single task, and up to 50% more errors. Doesn’t sound like something we want to do, right?

Too many things going on.

So what can we do to improve right now where we’re at? There are a couple of immediate actions, and perhaps a bigger, and more valuable, solution long-term.

First, product owners…

Tell the requestors “No.” In Henrik Kniberg’s wonderful overview video of the product owner role, he says practicing saying “No” goes a long way. I typically respond with a different version – “Yes, AND…” That is, “Yes, AND if you show me which of your previous requests this new request is more important than, we can do it at that point.” With tougher stakeholders, I’ll admit that I have said, “I’ll put it in the backlog right away!” I would do that (I don’t run around lying to executives), but I would sit on the request and wait if this the request was “urgent but not important.” Or perhaps they would soon be distracted by some new, bright and shiny thing. Ideal and healthy? Perhaps not. But there are some places that I felt I had to pick my battles and use my time responsibly and effectively for more value elsewhere in the company. And dealing with pushy or whiny Ryan from Department B wasn’t always it.

Managers and the PMO

Second action is for managers and the PMO – tell the requestors “No” by not starting up yet another team. The truth is, if you have 100 developers and testers in IT, then you should have about 10-14 teams. The numbers tell us that matrixing is costing us a massive lack of focus. It also costs you in lost opportunity. Rather than simply delivering the most valuable thing in a month, we often deliver the 1st – 12th most valuable things at the end of a year, with not much business value or feedback in the middle of that year. And value degrades. A customer-requested feature delivered long past peak demand is just not as valuable as delivered at the height of market/customer demand.

ScrumMasters

Thirdly, ScrumMasters and internal agile coaches should tell the requestors, “No,” by talking with stakeholders and decision makers about these costs. Over and over again, I hear those guiding the agile adoptions at their companies tell me they’re in a matrixed organization. They admit that they know it’s bad, but they’re hoping it will change. If we could be honest for a moment, if you’re in this situation, how long has it been this way? How long have you been hoping for change? As a change agent, have you shared this information with them? Is there any buy-in, a timeframe, or roadmap for change in this area? Most commonly, real organizational change (such as how work is fed to teams from the program and/or portfolio) begins with understanding and support from top executives and stakeholders.

One example of a framework for alignment at these levels is the Scaled Agile Framework® (SAFe™), which provides some nice guidance for addressing this problem. First, we work in terms of value streams, which certainly something the business should relate to, and all contributors within that value stream are on teams. A level above the team’s Product Backlogs is a Program Backlog with a product manager who is the single point of accountability for this larger span of work. Although this can be handled in pure Scrum with a chief product owner, figuring out how to implement this can be quite difficult. The following can take years, if ever, to figure out on your own (especially without external coaching, which most aren’t fortunate enough to have:

  • The “what” of a portfolio, strategic themes, vision and roadmap
  • The “how” of actual coordination and ynchronizing the work of many teams
  • Governance such as architecture or UX

SAFe gives you a running start in these critical, but typically shelved, areas.

Even more helpful to help executives understand and support agile is that SAFe gives a simplified and easy-to-understand (ok, easier) context and plan for your stakeholders and other key roles from whom you need support for change. Keep in mind that many feel that we are in the Late Adopter (from the Technology Innovation Adoption Curve) state of agile. These Late Adopters are typically risk-averse, don’t like change, and would like a plan – at least to start with. To tell them, “We’ll self-organize around how to do agile here and we’ll figure it out,” is probably not something they want to hear.

I hope you found some ideas in this article that you can take action on and help others in the organization do the same. If so, we can all get back to the good stuff – meaningful, challenging work that delights stakeholders and customers.

Posted in Agile Leadership, Agile Management, Agile Teams, Agile Velocity, Lean, Scaling Agile, Scrum Development | Leave a comment

What is the Prerequisite of Success When Scaling Agility?

Guest post by Timofey Yevgrashyn, Ciklum

Today more and more enterprises are looking into agile approaches as the answer to their needs. It doesn’t matter if a big company starts scaling agile with or without acting Scrum teams. What matters is the way the company goes from the “let’s-scale-agile” decision to the visible results of scaled agility.

Why scale agility? A few thoughts.

One could say that the apparent reason to apply scaled agile practices is when you have many agile teams that are cross-dependent and working on the same product(s). But it wouldn’t be true as in our practice; the number of people doesn’t drive managers to even start thinking about applying methods above the team level.

What interesting is, the decisions to scale agile often come from the top. The feeling of “something is wrong with the business” on the top level is much higher than that feeling at the team level where the use of Scrum or other agile methods usually starts.

While talking to more senior management, the problems could emerge through the main “pain” areas, which have been reported in a number of agile development studies. Briefly, these areas are quicker time-to-market, better quality of the product, higher engagement of people and higher productivity. One or another, or even combined pain feeling in these areas, leads the enterprise management start thinking about better methods or development practices that could help coordinate many agile teams. The company management itself, or with the help of consultants, realizes the need for scaled agile. And so they start looking for already known frameworks such as the Scaled Agile Framework® (SAFe™) or experiment with their way.

Scaling agility doesn’t come easy.

It is worth mentioning that an organization structure is the result of that company’s history. Rarely (not to say never) is organizational structure architected in a scalable way from the beginning.

To be able to deliver better software and respond to change at the same time, an enterprise should overcome the major pitfall in scaling an organization. This pitfall is the traditional mindset of project-oriented companies instead of value-oriented companies.

Many of you have seen the triangles picture. It shows how the sequential phased approach (aka waterfall development) is compared to agile development methods in their view on three cornerstones: (1) scope, (2) time and (3) teams – resources and/or budget:

triangle image_Tim

Many organizations with a desire to scale agility still approach projects in the old, traditional way. The business part defines the total scope, and the software development part (or a vendor) is expected to estimate and plan how many resources and months they need to deliver what they were told.

At the same time, the agility of an organization means delivering what users need and cutting out waste from the original ideas to maximize value. This demands that an organization build a structure that, at regular pace, delivers a working product and then just balance out the decisions of what to do next in order for the business to develop.

What companies do before scaling.

Organizing people and communications around value streams is one of the major changes that happens when a company decides to scale agility. Even if the decision “let’s scale agility” is supported from the very top level, and everyone is eager to achieve this state quickly, there’s still a long way to go.

In our practice, this change requires management and key people to review how the organization earns money and delivers value. Often the discussion on how to organize teams around value streams requires changes in the team’s composition. This leads to the human factor and necessity to take this change carefully.

While the top level, or portfolio level, usually focused on value streams alignment, the other part of the organization should review roles, responsibilities and authority levels. Looking on the team and program levels, the need for coordination between teams emerges and, thus, different roles are needed. Nevertheless, these new roles should not be mapped directly to the old company structure. Built from the agility point of view, the duties list for these roles would include: serving, coordinating, and enabling as the primary drivers.

SAFe produces recommendations on what functions are needed on different levels. But like any other framework (LeSS, DAD or simple Scrum), SAFe should be used with care and deep understanding of why the role is needed and what value it brings to the enterprise.

Above organizing around value streams, it’s worth the reminder that an actual software development team is just an intermediate phase from the end-to-end value stream point of view. This makes dependencies on the upstream (usually product analysis and requirements preparation activities), requiring a seamless integration with the downstream (usually stabilization, packaging or deployment).

While both boundaries are meaningful, alignment with the upstream – and especially with business decisions – is critical. As our head of consulting mentioned once to a client, “There is nothing worse than having a great software development team with a great and optimized agile processes, doing wrong things.”

Such initial misalignment in practices makes it apparent that the organization should learn additional methods for content/requirements handling and practices at the program and portfolio levels to support agility at scale. As experience shows, it takes time for those responsible for the content of the product to adapt these methods to a degree where agile teams see the difference between before and now.

Furthermore, if your organization hasn’t had a rhythm of delivering working and demo-able product on team levels, it is risky to launch a joint program with many teams working together and call it scaled agility. The gravity of non-delivering could pull back any well-educated and well-coached organization.

A Program cadence (sometimes called “a release”) is a higher level of the rhythm and alignment achieved when business, content and delivery people can agree on what, when and how. Even if an organization plans their first-ever release cycle together with starting sprints on the teams level, still it would take time before management in charge of the “let’s-scale-our-agility” idea could clearly see benefits and results.

Something would go wrong, definitely.

It seems quite a clear path of activities that an enterprise goes through from decision to actual scaled agility:

  • Reorganizing around value streams;
  • Identifying the missing or new roles and responsibilities;
  • Embracing additional Backlog handling methods on all levels (Portfolio, Program, Team);
  • Achieving a rhythm of delivering working and demo-able results and then aligning on the high-level cadence such as a release;
  • Adapting continuous culture change and keeping up the momentum
  • Our observations show that even having a clear guideline and proven scaled agile framework in-hand, many companies will deviate and take this path differently.

One of the major obstacles has always been, and remains, company politics and old-fashioned culture that oppose the initiative of agility at enterprise-scale. Even with support from top management having a long walk to go, scaling agile challenges persons and ambitions, and causes fears and uncertainty with every decision.

One of the major signs will be a continuous culture change that regularly happens. Such a culture shift could manifest itself in small improvements handled by a team daily. Or it could be regular, healthy and actionable retrospectives, or in a high-level alignment that allows many people to plan together and deliver what’s intended, without a big overhead.

The motto that helps my colleagues and myself be patient on this is “Scaled agility is not the goal, rather a direction.” Thus, even being armed with clear steps and frameworks, we continue helping our clients incrementally to gain value from transforming to scaled agility by inspect-and-adapt all the way.

 

Posted in Agile Adoption, Agile Coaching, Agile Leadership, Agile Teams, Enterprise Agile, Scaling Agile | Leave a comment