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


Catch James Chan’s talk on AgileLIVE Wednesday, December 10, 2014: “Portfolio Strategy + Agile Execution: Coordinating, Not Competing.” Details at

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

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.


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



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.


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.


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, 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 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 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

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, 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.


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

The Next Generation of Project Management

Guest post by Chuck Cobb, Breakthrough Solutions/The Business Excellence Group

The concept of agile project management is very rapidly evolving and will have a significant impact on the project management profession, causing us to rethink many things we have taken for granted about what “project management” is for a long time.  However, we are in the very early stages of that transformation and there is a lot of confusion that exists in today’s world between the agile and traditional plan-driven project management (aka “waterfall”) communities. Many people see them as competitive and mutually-exclusive alternatives.  Some of the factors that contribute to this confusion are:

  • Many stereotypes and misconceptions exist about both agile and traditional plan-driven project management
  • Agile and traditional plan-driven project management principles and practices have been treated as separate and independent domains of knowledge with very little or no integration between the two
  • Agile and “waterfall” have been treated as binary, mutually-exclusive alternatives and many people make the mistake of force-fitting a project to one of those extremes

It’s no wonder that project managers and others might be confused by all of this!

A large portion of closing the gap that exists between the agile and traditional plan-driven project management communities can be attributed to a mindset change that includes:

1. Getting past a number of stereotypes and misconceptions that exist about both agile and traditional project management

2. Broadening our thinking about what “project management” is

Here are a few examples of the most popular stereotypes and misconceptions that exist about project managers:

1. Project managers are very “Command-and-Control” oriented.”

There is probably some reality behind this stereotype. Project managers are noted for getting results and sometimes that means being assertive and somewhat directive to set goals and manage the performance of project teams; sometimes that’s necessary.  Many times that behavior is expected of a project manager by the businesses in which they operate.  For example, if a project team is underperforming, the project manager is the one often held responsible and is expected to take corrective action to get the project on track.

2. Project managers are rigid and inflexible.

This stereotype also has some reality behind it, too. For many years, project managers have been held accountable for managing the costs and schedules of projects; and we all know that in order to meet cost and schedule goals, you have to control the scope of the project. That, in turn, requires a disciplined approach to managing change where change become the exception rather than the norm.

3. Project managers only know how to manage by the “waterfall” methodology.

The emphasis on managing costs and schedules for a long time has required accurately defining the requirements upfront, which leads to extensive use of “waterfall-style” methodologies that are based on trying to define project requirements in detail upfront before the project starts.  The emphasis on cost and schedule management is a significant reason why that approach continues to be used today.

4. Project managers are just not adaptive and cannot adapt to an agile environment.

I don’t believe that stereotype is correct, but it does require a significant shift in thinking for a project manager to make that adaptation. A good project manager knows that you have to adapt the project management approach to fit the problem rather than force-fit every problem or project to a single approach.

It should be apparent from all of these stereotypes that many of these behaviors are a function of the environment in which project managers operate, and are influenced by the expectations that businesses have of project managers. Creating a broader image of what project management is will also require influencing the environment and expectations on project managers.

Here are a few examples of the most popular stereotypes and misconceptions that exist about agile:

1. Agile projects are totally unplanned.

There is actually a lot of planning going on — It’s just a different kind of “just-in-time” planning that is more spread out through the project rather than being done heavily or totally upfront.  However, doing upfront planning is definitely not inconsistent with an agile approach. As an example, I was asked to rescue an agile project where, two years into the project, the project had no end in sight, and senior management had lost confidence that it would ever produce results. When we re-planned the project, we discovered that the scope of the effort was just too large to be done by a single agile team in any reasonable amount of time. If more upfront planning had been done, this problem would have been discovered much earlier.

2. Agile projects do not use any process and are totally uncontrolled.

That stereotype is also not accurate. Most agile projects use Scrum, which is a very well-defined process.  It’s a different kind of process – it is much more empirical and adaptive rather than rigid and prescriptive, but it is a well-defined process. It is also not difficult to apply whatever level of control you want to an agile project.  As an example, a few years ago I managed a large U.S. federal government project for the Federal Aviation Administration. We were able to create a hybrid model with a sufficient level of control to meet government contracting requirements, but at the same time provide a sufficient level of flexibility to further define detailed requirements with an agile development process.

3. There is no project management required for an agile project.

Although there may be no one with the title of “project manager,” in an agile project at the team level, there is plenty of project management going on.  It’s just a different kind of project management and the project management functions are distributed over a number of different people on the team rather than being held by one particular individual called a “project manager.”

  • The product owner in a Scrum project performs many project management functions by setting the direction and priorities for the project and making decisions as the project progresses; he or she is responsible overall for the success or failure of the project from a business perspective.
  • The ScrumMaster performs some project management functions by facilitating the team and the process, and is also responsible for removing obstacles that impede the team’s performance.
  • Everyone on an agile team performs some very basic project management functions in planning, estimating, and managing their own work, as well as tracking and reporting progress. Each member of the team as a whole must also coordinate and integrate all the activities of the team.

4. Documented requirements are not consistent with agile. Documentation is still useful in an agile project where it adds value.  Of course, documentation should not be done for the sake of creating documentation; however, there are many situations where it makes sense to document requirements in an online agile project management tool using a simple user story format as the project progresses.

In “The Next Generation of Project Management,” we need to:

  • Broaden our thinking about what “project management” is and think of it as a function, not a discrete role associated with someone called a “project manager,”
  • Develop a fully integrated agile project management approach that blends both agile and traditional plan-driven approaches in the right proportions to fit a given situation when necessary, and
  • View agile and traditional plan-driven project management approaches as complementary to each other rather than competitive

This is a significant challenge and will require a lot of new thinking, but it can be done.

It feels very similar to an evolution that took place when I worked in the quality management profession in the early 1990s. Up until that time, the primary emphasis in quality management had been on ‘quality control’ and inspection; the image of a ‘quality manager’ was heavily based on managing those functions.

  • The predominant quality management approach at that time was based on inspecting products before they were released from production prior to shipping to the customer and rejecting any that didn’t meet quality standards. It’s easy to see how that approach was inefficient because it resulted in a lot of unnecessary rework to correct problems after the fact and it also wasn’t that effective because any inspection approach is based on sampling – and it’s impractical to do a 100% sample. For that reason, this approach can result in a very mediocre level of quality.
  • A far better approach was to go upstream in the process and eliminate defects at the source by designing the process to be inherently more reliable and free of defects. That didn’t mean that the prior emphasis on quality control and inspection was obsolete and eliminated; it was just not the only way to manage quality, and wasn’t the most effective approach in all situations.
  • At the same time, “quality” took on a much broader meaning. It was no longer sufficient to produce products that were free of defects; producing products that were free of defects became just ‘table stakes’ to play in the game.  To be successful, companies really needed to go beyond that and produce products that really delighted their customers.

That was a gut-wrenching change for many in the quality management profession. Instead of being in control of quality and being the gatekeeper with the inspection process, a good quality manager needed to become more of a coach and a consultant to influence others to build quality into the way they did their work.  This changed the nature of the work dramatically for many in the quality management profession and eliminated a number of traditional quality management roles that were based primarily on the old quality control-and-inspection approach.  The similarity to the changes going on in the project management profession should be apparent:

  • Project managers needed to recognize that simply controlling the costs and schedules of a project was no longer sufficient; the project had to be successful from the perspective of producing value for the customer as well.
  • To be successful in more uncertain environments and focus on producing value, project managers need to be able to take an adaptive approach that is appropriate to the level of uncertainty in the project.
  • Finally, they need to give up some of the control that has become associated with the project management profession – in some cases, they may need to become more of a coach and a consultant to influence others rather than being in absolute control of a project.

This can dramatically change the role of a project manager and, in some situations, the role of a project manager as we’ve known it may no longer exist.  For example, at a team level in an agile project, you probably won’t find anyone with a title of “project manager” because the project management functions have been absorbed into other roles and are done very differently.  That doesn’t mean that project management is no longer important, but it may cause us to dramatically rethink what “project management” is in a much broader context than the way we may have thought about it in the past.[1]

About Chuck

Chuck Cobb is an Adjunct Professor at Boston University where he will be teaching a brand new, graduate-level course on agile project management. He is passionate about helping close the gap between the agile and traditional project management communities. To that end,

  • He has published two books on agile project management (a third book entitled “The Project Manager’s Guide to Mastering Agile” will be published in early 2015 by Wiley Publishing)
  • He has written over 50 articles on his blog site and has recently developed an online training course to help project managers learn how to develop an adaptive approach to project management that blends agile and traditional project management principles and practices in the right proportions to fit any situation

Chuck has worked with VersionOne for a number of years and has devoted a portion of his new book to using the VersionOne agile project management tool as an example of the importance of using tools in an enterprise-level agile project management strategy.

[1] Cobb, Charles, “The Project Manager’s Guide to Mastering Agile – Principles and Practices for an Adaptive Approach, Wiley Publishing, 2015

Posted in Agile Adoption, Agile Benefits, Agile Project Management | 3 Comments

Time to Celebrate with Great Reviews!

Someone recently asked me what one thing would make any company’s Agile transformation and adoption more successful? Almost before the question left their lips, I shot back – “great reviews, company-wide great reviews!” The most mature Agile organizations I’ve seen have regularly scheduled company-wide review meetings. These reviews are light on presentation and heavy on demonstrating working successes. The other positive factor for these review ceremonies is that they have active participation by managers, leaders and C-Level executives. These organizations regard reviews as sacrosanct, too important or valuable to be interfered with.

During my Certified Scrum Master (CSM) training a few years back, our class was struggling to find an answer to the Magic Management Metric question. The Metric that enables managers to say, “Ah-ha! Now I get this whole touchy-feely, self-organized Agile mindset thing.” Our instructor was a little put off by the idea that we needed to prove our worth and the value Agile brings to the powers that be at our respective companies. His terse final answer was that “If a leader wants to know what the team is doing, come to the review!”   After all, valuable working software delivered on a continuous basis trumps everything, doesn’t it?

Unfortunately, the reality is that the teams have become victims to our own self-crated Frankenstein’s monster. Most self-managed teams haven’t made it easy for leaders to attend even a handful of reviews. Each team plays by their own set of rules: some use two week iterations, some deliver daily but you can probably be sure that only 10%-20% of the reviews happen on the same day and even fewer happen at the same time.

This could be one of the driving factors towards the need for a more scaled multi-team view for agile delivery that is becoming more popular in the marketplace today. Process and program are seen as the glue that will bring various teams to communicate together. It’s not that companies don’t value individuals and interactions; they just value process and tools more, because the other way isn’t working too well.

The reality is that it is still desirable and possible to deliver customer value across self-organized lean teams, and many great companies are succeeding in doing so.   One way is by adopting regularly held All-Company Agile celebratory review meetings to help foster the collaboration and communication team need to be more effective. It’s still about the interactions and delivering working software. For any enterprise looking for a better way to radiate information on a consistent and customer focused way, here are some ideas to help your teams and leaders engage and execute healthy “All-In” review ceremonies:

  • Have ONE all-company review meeting; every team and every leader should be represented. This is sacrosanct, and it is the highest priority meeting on people’s calendars.
  • Teams need to synchronize their review cycles to a regular meeting cadence. This can be helped by having teams align to their iteration schedules.keep-calm-and-review-it
  • Have a set schedule order for who is speaking, but don’t over prepare. Keep it concise, but allow enough time to show each team’s results.
  • Each team gets an opportunity to demo their valuable customer working software during the review. Use collaborative online meeting options like GoToMeeting, if you have distributed teams.
  • When it makes sense, show your customer using the new and improved software. DevJam’s David Hussman recently recommended using your mobile devices to record customers demoing the software as a great way to accelerate Product Driven Learning. You don’t need a documentary, just live, real video feedback.
  • Reviews should be Agile method agnostic. You can regularly review the valuable accomplishments of SCRUM, XP and KANBAN teams at one time. It’s okay!
  • Cheering, hooting, clapping, and congratulations are encouraged. It’s called a celebration for a reason. Woot, Woot!
  • Feedback is encouraged, but even more important is having leaders engaged, present and observing what is and is not working and learning how to, as’s Leadership Engagement model shows, Encourage Monitor and Remove Big Impediments to support future team success.
  • Facilitate the time for feedback collection and Q&A to help keep the meeting on track. Use other creative methods like breakouts, note cards, or a simple post-review on-line survey to collect and report feedback back to the product owners and teams.
  • Course correcting is still reserved for the team-led retrospectives. Teams should regroup soon after the review, provide feedback and make tuning observations to improve future results. Then the actions should be shared, and provided to the appropriate levels across the org.

The interesting thing I’ve discovered from observing All-In reviews is that when everyone from the CEO down to the Summer Intern celebrates the wins of two weeks of effort, multiplied by many teams delivering substantial value to customers on an early and often basis, everyone wins. EVERYONE!

What types of actual results might you begin to see using ALL-IN reviews?

Team health becomes more transparent and the need for health-check driven metrics is reduced.   This increases the time available for productivity gains and the overall delivery team morale. Quality is more apparent, defects are reduced and the feeling that I should check my Facebook or LinkedIN pages at work goes down. Leadership’s motivation to remove impediments and understand “the system” and the knowledge of what is truly going on goes-up. And finally, the ability to achieve shared company-wide goals and demonstrate the ways teams are impacting customers in a positive consistent way is recognized and encouraged to thrive.

Tom Peters says you should “Celebrate what you want to see more of.”  Our highest priority should be to review team accomplishments, promoting even more success, more agility and more happy customers!

Posted in Agile Adoption, Agile Benefits, Agile Management, Agile Project Management | 3 Comments