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.
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.
- Expect working software to be demonstrated at the end of a sprint. If it can’t be demonstrated, it’s not done.
- 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.
- 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.
- 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.
- 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.
(Guest blogger and Rally user Erine Gray is the founder of Aunt Bertha, a software platform that makes it easy for people to find and apply for food, health, housing and education programs in the U.S.)
This is the story of how Aunt Bertha used Rally to get our team organized, communicate better, and start loving each other again. It was kind of like group therapy.
I’m only sort of joking. Our team doubled in size this year and there are now more people writing code. There’s more knowledge to be transferred. There’s more testing that needs to be done. There’s more that can go wrong. And things did go wrong; like any relationship, communication is key.A Story
We had a new customer, Critical Mass, who wanted its users to be able to know if they qualified for a local cancer program using rules common in the cancer program space: current age, age at diagnosis, type of cancer, and current stage of cancer. We’ve always had ways of determining whether someone qualified for a program based on their income, but we didn’t have an easy way to extend this qualification to other eligibility rules, like these.
Ideally, a cancer survivor should be able to see—with the click of a button—whether or not they qualify for a cancer program, and why. They should be able to see something like this:
Since Aunt Bertha’s mission is to make program information accessible, we were excited to build this feature into our product. However, we had a problem.Teamwork and Knowledge Transfer
When we first started using Rally at Aunt Bertha, we had two new programmers on the team. I was the lead developer, and I was terrible at knowledge transfer. Release after release would go by and features were not delivered on time. And it was my fault.
I had no doubt in my mind this feature should be built, and I knew how I was going to do it. I had a vision of what it was supposed to look like and a rough idea of how the algorithm would work, since I’d written most of the search code over the last three years.
The trouble was that building this feature was going to be a significant amount of work, and I didn’t have time to build it. Programmers are typically optimistic about how long it takes to do stuff, but we have short memories. It’s kind of like golf: we only remember those great drives that lay up perfectly on the fairway; we don’t remember the time we spent digging through the weeds to find our ball (or the late nights spent debugging only to find out we put a semicolon in the wrong place.)
Aunt Bertha was also in a growth phase. I didn’t need to be the lead programmer anymore. I had to delegate, but I was afraid because I knew that this feature would touch hundreds of lines of code that only I understood.Enter Rally
Around this time our product manager, Ruby, started implementing Rally for our software development process. Prior to Rally, we had used Github as a code repository and for issue tracking. It was a nice, lightweight way of keeping track of issues and milestones, but now we had more developers and staying organized was a real challenge. We needed more rigor and structure.
I didn’t know much about agile software development. Ruby implemented a bi-weekly sprint planning meeting, and gave us all homework. Our job was to look at all of our stories, and break them down into digestible tasks.
I took the Critical Mass eligibility rule story and began to break it down. In the past I would typically jump into a feature, only to discover later just how complex it was. Breaking down a feature into stories and tasks really forced me to think about the problem in small chunks. That was when the light bulb went off in my head: I could indeed delegate some of these tasks to our new developers. I didn’t have to be the one to do it all; I just had to coach them along.
I’m happy to report we built a pretty amazing feature that’s making it easier for cancer survivors to navigate the myriad programs out there. Our developers can now dig into the most complex code, and I can now concentrate on getting new customers and setting the longer-term vision for the product.
Rally helped us communicate better, and set deadlines that we could actually make. Rally helped us understand that big problems are nothing but a series of small problems.Making It Fun
One of my favorite views in Rally is the Story Estimation screen.
After we’ve developed our stories and added the requisite tasks, our next step is to estimate about how long a story (or feature) will take to build. This screen allows you to easily drop in a story by the estimated size. We size ours based on the size of our dogs (we’re a dog friendly office.)
A small story is a “Cinco.” A “Rosie” (that’s my dog) is a medium-sized story. A “Beowolf” (Chris’ dog) is a big story.
Cinco, Rosie, and Beowolf represent small, medium, and large story sizes
It may seem silly to estimate your workload this way, but the truth is that sizing is relative. What matters is how many Beowolfs, Rosies, or Cincos you can accomplish in a two-week sprint.Why We Chose Rally
We considered plenty of options: we could have just stayed with Github, and we looked at Rally competitors. But we ended up going with Rally for a couple of reasons. One reason was that Rally offers its products at a discount for fellow B Corporations (Aunt Bertha has been a B Corporation since 2011.) The primary reason, however, was an encounter I had with Rally’s founder, Ryan Martens.
Ryan was a mentor at Boulder’s Unreasonable Institute, and when Aunt Bertha went through the 2012 Unreasonable Institute in Boulder, I had a chance to interact with Ryan. During that summer the team would spend most evenings with mentors: getting our questions answered, hearing about their experiences, or just sharing stories. I distinctly remember one of Ryan’s comments on business and ethics: the passion of his delivery and his desire for our success made me a fan immediately. Simply put, he seemed like a guy I wanted to be like, someday. And Rally is a company we want to be like someday.Erine Gray
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.
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
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
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.
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.
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 5 – Sprint Zero Summary
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
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
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
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:
- Scrum Process Overview & Guide to the Five Levels of Planning
- The #BecomingAgile Webinar Series Archive (each worth 1 PDU)
- An Online Agile Glossary of Key Terms & Definitions
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 firstname.lastname@example.org 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 email@example.com or on Twitter @lesliejdotnet.
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.
It doesn’t need to be a contract. I find it useful for setting the quality bar for my teams. Also avoids miscommunications amongst teams, product ownership, and other stakeholders.
I have been burned in the past by developers claiming things to be done when they were clearly not.
-by Mark Lines on 11/17/2014 at 3:08 PM
I tend to agree with Mark on this one. I have not used “Done” as a measure of functional completeness (which would make it more of a contract. I have used it kind of as a “nonfunctional checklist” (if that even means anything) of completeness, that applies regardless of the functionality. It’s not done until it’s code complete. And automatically deployable. And has a sufficiently complete automated test suite. And has been code reviewed. Or whatever the list happens to be in the present context.
Does that make sense? It’s not a contract between dev and customer. It’s a contract between and among the dev te and itself. And it describes ways of working, not functional output.
-by Bill Barnett on 11/17/2014 at 6:20 PM
Bill, it starts innocently enough. But take a look / listen at how this is taught, described, lectured written, and behaved. You’ll see contract negotiation start instantly. Which is what prompted the posting.
It’s not that I don’t understand the pressures and reasons for having a DoD != shipped. However, DoD is all about the distance between what really got done and potentially shippable. If that distance is zero, no problem. If not, contract negotiation starts, and bad things almost inevitably ensue. Hence the post.
-by Alistair on 11/17/2014 at 6:38 PM
What’s with the image in this post? Is that a gardening tool?
-by ksteff on 11/17/2014 at 9:12 PM
hah, ksteff, that’s me in a hurry to find a pic. I was looking for a spike in the ground. no good one, but this was too cute to pass up.
I have come at this from a slightly different angle, having recently helped two smaller companies set up PMOs and their own best practices as they transition into enterprises. The challenge both of these organisations have faced is that they deal with customers who are much larger and insist on fixed price contracts. Both companies in question have managed to exert influence on their customers but it is a slow process and flexibility was the key.
The approach I took was to have the Product Owner (played by internal BAs liaising with the customer) agree a high level Product Breakdown (yes, this is a PRINCE2 term but the end Products / Deliverables can be made to map nicely onto Epics for software elements) with Acceptance Criteria agreed by Deliverable / Epic. These Acceptance Criteria go into the contract, giving the Product Owner freedom to negotiate the Story-level Acceptance Criteria in each sprint. This meant that the core functionality “as a user, I must be able to…” could be agreed up front while the mechanism for achieving this could be set on the fly. Any changes to the core functionality result in formal Change Control with associated contract haggles but this was infrequent and isolated from the devs.
Done then becomes a combination of the dev best-practice activities listed by Bill, above, with proof that the story-level ACs have been met. For this sort of work, it is vital that the story-level ACs are included in Done as it is not possible to forecast internal project costs effectively if they are not.
Regarding costs, we agreed a relatively high fixed price contract but on a call-off basis and subject to change control at the Epic level. This is not a pure agile approach as, by necessity, all Epics and some Stories need to be defined up front to set the initial fixed cost but it does still leave a lot of flexibility at build time.
s. the item in the image is a pin for securing your dog when camping, etc. You screw it into the ground, then clip the dog’s lead to the round eye which is free to swivel around the pin. Good if you are around, but not safe to leave a dog unattended as they can get caught up and strangle themselves. Experience shows they can also be used as a tent tie-down in strong wind!
-by James Pels on 11/18/2014 at 6:27 AM
The point here is to be agile. If you don’t want to be agile, that’s fine. But don’t pretend you are (and definitely don’t tell people you are) if you have contracts and they take precedence over learning (and adapting) together with your customer.
Personally, I prefer a story as a “promise for conversation.” One of the hardest things to do with a software team that isn’t used to this agile thing is to convince them to go talk to their customer. Often. :-)
P.S. Thanks for the prod, Alistair!
-by Stephen Starkey on 11/18/2014 at 7:00 AM
yep, that’s it, Stephen. You don’t have to pay attention to any of the values in the manifesto. None of them are mandatory. AND, also, contracts have a useful place (as it says in the manifesto). BUT, still, if you say you’re using the manifesto, start listening to DoD as contractual negotiation, and you might be surprised as to what you discover. I read all the above notes as “we like/need contracts because….”.
Maybe the language is more along the lines of
‘Is this (system) currently working for you?’ as a business question.
This can be answered with a range of responses e.g. “no, because” or “yes, but” and can be directed at a set of stakeholders – “it works well for me but not for accounts”. The business is then responsible for what working for them means (efficiency/speed/value).
Done becomes ‘working well enough that it is now time to concentrate on other things’
Also by saying ‘currently’ you acknowledge change is inevitable. Can also tie this in to automated testing.
-by jimduk on 11/18/2014 at 8:56 AM
+1 with Mark & Bill. It seems, and I use, DoD as an internal agreement only defined by and for the team. It’s a checklist per se, some kind of half-explicit knowledge / know how to assure a certain level of reproducibility / quality.
You are right though, the way it’s used / taught is exactly the opposite. But we just can’t stop using something because lots of people do stupid thing or interpret it in a way bending the ideal. Or I could stop explaining Agile/Lean is a good way to deal with product because some people are doing bad Agile ;)
-by stephanewww on 11/18/2014 at 10:04 AM
or you could amplify exactly that that Stephen suggests, more actual meaningful dialog between programmers and sponsors and end users. With running sw in hand.
The image for this post is a stake that gets used to tie down animals for grazing a field (so they can only move within the circle defined by the length of the rope). That can be interpreted in some interesting ways in this context, I think. Food for thought.
-by Oluf on 11/19/2014 at 11:26 AM
One 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 first 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.
The 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.
- Customer collaboration over contract negotiation ( ref: http://agilemanifesto.org )
Definition of Done is a contract.
The wonder part got me thinking.
Recently looking out at the stars – I thought – they could all be gone and we’re just getting their last light – JUST KIDDING. No – I thought, gee, this notion of ‘big bang’ which is really ‘creationism’ sold as a Snickers bare when it’s just another OHenry bar – somewhat leaves me feeling robbed of my potential for awe.
Which is more more enticing ? the intellectual torment of how everything could come from nothing? or – that they just go on forever. Aristotle adopted the latter view, and I now settle on the latter view. I currently argue, if everything came from nothing, clearly it was nothing, or it would still BE nothing.
Every 5 year old hits that flaw in causality after being told “Why – God created the Universe” after chasing causality of 24 Why’s in a row… Only to retort “But mommy, who created God” – many parents just don’t know where to go at that point. I contend the model is incorrect.
Same with say – ‘time travel’ – if you just let go of an inferior linear temporal model ? you won’t have the Grandfather paradox (“Back To The Future”), after all it’s really an intellectual abstracted model we overlay to event phenomena, time doesn’t really ‘exist’. If that’s true, and Einstein says time and space are really two facets of the same thing, YIKES, what did I just infer about space.
Either way – those words ‘just wonder and wonder’ above, reminded me of when I realized I’d much rather contend the stars do go on forever and ever, with jaw dropped awe and wonder vs. the intellectual torment of how anything could come from nothing.
“So look and wish, and wonder”
Bout sums it up. Sometimes I think I’m content JUST to witness that anything COULD exist at all. A wish ? is truly ‘will’ – a ‘thought’ and all in all ? I’ve given this much thought as to who anyone is, or I am. Am I my name? No that’s inherited. Am I my genetics ? those are inherited too. Am I my income (currently zero – but transient), my language ? nope – inherited culture, I didn’t create all those words. So at the end of the day ? I can’t come up with anything BUT one thing, that CHOICE one has to choose what they think next. I COULD think about hmm – say Sloths right now, or maybe Lime Greed Koolaid I had as a child once, or say – whether there are more even or odd numbers in an infinite set, or maybe Chicken and – well- you see where I’m going. So – a WISH – IS a WILL – a CHOICE. My take on things ? In the ends ? It’s like Phil Connors in Groundhog Day “Ya make choices and ya live with em” – I now identify more with that ability to choose what one can think over what one thinks. I think in non being, I’d miss thinking most, I may not miss thinking about missing thinking as much as I’d miss missing thinking, perhaps not.
To look, to wish, and to wonder… Indeed. There is doing, but ultimately that’s pegged causally to the wish to act.
I need sleep, since I can’t comment on UML – and modelling, since I still don’t comprehend it all, eh – thought I’d maybe share something of value to me to invoke further wonder !
-by Tim Miltz on 11/16/2014 at 9:29 PM
Pancakes and EGGS!! Humpty is a CANNIBAL! ? ? ! ? ! oh the horror… sob, sniffle…
-by michele on 3/11/2010 at 8:13 PM
LOL, busted! good call, Michele!
-by Alistair on 3/13/2010 at 3:12 AM
I feel this is the only section of your site I’m qualified to offer any insight :)
Two comments KIND of related.
One ? I recall seeing this Japanese man or woman, who had earned the title oldest human alive, when asked what one common denominator they could find in diet, they said they ate an egg every morning of their life.
Two, giving thought to resolve this Chicken or the Egg paradox ? I think I’ve solved it – it’s really a question abou temporal state. Ok, I said temporal just to sound impressive (46, but STILL A child in so many ways). In realizing the chicken and the egg ARE one and the same ? just two different states ?
I think I’m ready for early retirement.
I JUST discovered you Alistair – I started programming as a child age 8 in 1976 or so on this Honeywell CP5 our Univ. had, and I have always struggled with UML and ‘use cases’ to all of last week I’m reading and reading, and I still can’t figure out just how specific or generalized they are supposed to be- and then all this story boarding or something, then reading – oh no – that doesn’t get you context, I found you were the culprit behind this entire movement :) All respect heh – so – just saying hi, and very cool to be able to do so. That’s all. Hope I brought a smile, because I don’t think I’ll be bringing anything useful on use cases, since I still…struggle with them.
Some of my other favorite mottos ? Always better days ahead but I haven’t been able to prove this one. I also realized recently, I don’t have to worry about dying, I’ve already not existed before I was born and the world existed just fine then. So clearly, statelessness in being isn’t anything new.
Very cute poem above. Heh.
REGARDS- I can see you have a built in smile- that’s all I have to say.
-by Tim Miltz on 11/16/2014 at 12:33 AM
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 many 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.
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.
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:
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.
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.
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.
 Cobb, Charles, “The Project Manager’s Guide to Mastering Agile – Principles and Practices for an Adaptive Approach, Wiley Publishing, 2015
I’m setting up this page for the explicit purpose of collecting votes on the User Manifesto (discussion: Re: User Manifesto).
To change the Votes below, click the Edit link there, and put an additional 1 next to your choice. Then click the “Save + View” link below the text box. That will produce a long string of ‘1’s as the vote. If you want to be nice, put a space after every five ‘1’s for easier viewing. And then don’t delete anyone else’s vote, for goodness sake – this vote doesn’t elect a president or anything, so there’s no real meaning to “winning” the vote.
On the other hand, you can just write down your preference in the Discussions pane.
Put your name and choice down below the votes if you’d like others to see your choice of voting.
If you want to propose an alternate linguistic structure for the manifesto, don’t do that here, add that to the User Manifesto Discussion itself.
Here, I’ll set up a start:
User manifesto choice A: 11111 111
User manifesto choice B: 11111 11111 11
Alistair: choice A
Markus Gärtner: choice D
Evan Sanders: choice A
Inbar Oren: choice B
Geraldo Xexeo: choice B
Cloud-based software development definitely changes how project managers need to approach their projects and lead their teams. Cloud development is not the same as traditional software product development and requires a unique mix of traditional project management and agility. Project managers considering working on cloud-based projects need to read what Sridhar Kethandapatti has to say.