If you are someone who is passionate about agile, the word “Waterfall” is usually used in a derogatory manner or, at least, when you use it — you are making the stink eye. On the converse, if you are someone who practices what is popularly known as “Waterfall” Project Management, you generally get offended or defensive when the word “Waterfall” is used.
Here’s how the conversation plays out:
Agile practitioner: ”There’s no way I’ll ever work on a Waterfall project.”
Waterfall practitioner: “There’s no way I’ll ever work on that Agile project.”
Agile practitioner: “Waterfall projects are never successful and I hate being told what to do.”
Waterfall practitioner: “Well at least we do work and don’t practice that Agile witchcraft and all that kumbaya mumbo-jumbo.”
Agile practitioner: “Well, your mama said Waterfall is for losers.”
Waterfall practitioner: “Don’t be talking about my mama!” …
The sad part about this dialog is that although it’s somewhat fictitious, I’ve heard similar arguments at organizations and with colleagues who work across all spectra of the project management continuum. The funny part about the dialog above and, in particular, the word Waterfall — is that no one is really clear who started calling it Waterfall. It’s obvious that when diagramming out a sequential process, it looks like a waterfall:
Often, people credit Dr. Winston Royce with Waterfall project management, especially with respect to software engineering when, in 1970, he wrote a part in a white paper that describes this approach (read it here). The funny thing is that he goes on in that same white paper that is credited for starting the Waterfall practices to describe how risky it is, and that, in order to mitigate the risks, each stage of the Waterfall process should do things iteratively and incrementally.
Waterfall project management is really Sequential Project Management. Meaning we perform a sequence of activities and there are generally stages, maybe with sign-offs, and usually hand-offs, to another group of people who are charged with performing the next sequence and consuming the output of the previous sequence. Some refer to this as Traditional Project Management, but in most environments its called Waterfall.
I’m not going to discuss the differences between the two and which approach I think is better — it should be clear since you are reading an agile blog. I will say that I think that the merits of each approach are obvious and each approach has challenges. The usage of one approach over the other really depends on the project and possibly the people engaged.
What I am going to say is that, in the world in which we all live today, it is very likely that we’ll have a mix of projects using a more of an agile approach and one using more of a Sequential approach. Sometimes we’ll have to join forces and combine the output of these approaches into one. Of course, we are learning and adapting ways to do this, but that too is another discussion altogether.
Let’s face it, when words start dividing people, we probably shouldn’t use them any more. Instead call the project management approaches what they are – iterative and incremental, or sequential, or continuous, or simply ad hoc. Also, be aware that the moniker we place on people isn’t really on the people; it’s on the processes by which they may operate in — and they may be really comfortable in that process. Generally, they’ve put in a lot of blood and sweat to make it work. Sometimes we need to put the monikers aside and focus on “individuals and interactions over process and tools” (crazy how I got the Agile Manifesto into this blog, isn’t it?).
For now on, be aware and call it Sequential Project Management or even Traditional Project Management — unless you want to get in an argument about “your mama.”
While at a recent Project Management Institute (PMI) event, the question came up of whether you could use agile techniques in Construction Project Management (after all, not all PMI members are IT Project Managers). Earlier in my career I worked for some electrical contractors, and thus have some first-hand experience in the Construction industry.
My first inclination was that agile would not be a good fit; but after doing some research, it turns out there are some examples of the application of agile and Lean principles to Construction (see also sources below). After all, software development is often contrasted with construction.
In general, agile is more applicable to the execution portion of a construction project, as there still has to be some fairly serious upfront planning. Major changes late in a construction project are generally hard to do efficiently. Also, the key principle of incremental delivery of value in the form of working software does not translate well to construction. However, agile concepts such as customer collaboration and responsiveness to change have a place in a construction project. Lean methods applied to construction are beneficial in regards to creating material and information flows, maximizing value generation, and the use of plan-execute-and-control paradigms.
Once the overall design and master schedule for the project has been created, then a method known as the Last Planner System can take that master schedule and provide a process for breaking work down into smaller units that can be executed more iteratively:
At a more tactical level, here is one way that typical Agile terms could be translated for use in Construction:
In his post, “An Agile Construction Project,” Chris Klein has some ideas on how agile roles would be represented on a construction site. For instance, the Superintendent could be the ScrumMaster, as s/he would be responsible for running the various meetings and coordinating work on the site. The Project Engineer or Project Manager could fulfill the Product Owner role, as s/he would be responsible for maintaining various project artifacts, make decisions on various questions around interpreting design specifications, and could represent other stakeholders to the project team similar to a Scrum Product Owner or Product Manager.
Chris also talks about how the various meetings and ceremonies of agile and Scrum might look in a construction setting. The Daily Standup would be more of a Daily Status Meeting where the various trades would coordinate their efforts and the Superintendent coordinates to remove impediments. Once an iteration cadence is established (how Sprints would work in a construction setting would vary project to project) there could be planning meetings and reviews associated with those iterations that would support collaboratively planning and reviewing work found in agile. There could even be sessions to review the processes being followed on the job site that would look much like a Sprint Retrospective. After all, both agile and Lean are all about continuous improvement, and Agile Construction Management would want to reap the benefits of this practice as well.
This is still an emerging concept in application of agile methodologies, but may have more relevance as the prospect of large infrastructure projects such as an expansion of broadband Internet and the creation of a Smart Electrical Grid could stretch the capabilities for existing construction project management methods.
Below is a list of the key references that I used in putting together this post. These provide a good starting point if you would like to learn more about Agile Construction Management. There will also be a post in the VersionOne Product Blog that will give an example of how these concepts might be implemented in VersionOne.
Thanks for reading; please share with us your comments and questions below.
An Agile Construction Project by Chris Klein: http://chrisklein.wordpress.com/2009/11/02/an-agile-construction-project/
Agile and Lean Applied to Construction by Adrian Smith: http://ennova.com.au/blog/2011/09/agile-lean-compared-applied-construction
Agile Construction Projects by Brian Doll: http://emphaticsolutions.com/2011/04/23/agile-construction-projects.html
Lean Agile in Construction Projects – 9/11/11 – 10 Years Later (Agilescout): http://agilescout.com/lean-agile-in-construction-projects-91111-10-years-later
Do you want to have more effective daily stand-ups? Do you want to have the planning meetings flow better and increase the value of these meetings? Do you want to see continuous improvement flow from your retrospectives? If your answer is yes, then put it on the Team.
I’ve written about trust, relying on strengths, and improving self-organization many times — and the message of these can be summed up as “Putting it on the Team.” Make the team responsible for solving problems; make the team responsible for defining how to deliver; and making the team accountable for delivery.
Most of the times when we talk about the concept of the team self-organizing, is it more focused on the “how” part of delivery, and not the process. However, remember that the meetings (or ceremonies as some call them) are primarily for the team. Specifically, the Iteration Planning, Daily Stand-up (or Daily Scrum), and the Retrospective meetings — these are for the team, not the stakeholders or managers. Do the stakeholders and managers gain value from these meetings? Yes, but the real value is the fact that the team takes ownership of what they are going to deliver; they take ownership of holding each other accountable to deliver and work through problems themselves; and they take on the responsibility of improvement.
A lot of times we (as in Managers, Scrum Masters, Team Leads, Type-A Team Members) want to install processes and templates around these meetings. This usually happens after a few weeks or several months of trying an agile development framework and either not following the guidelines of the framework or the team not taking the initiative to make improvements. We’re not getting any value and the team is resisting and or blaming the whole concept — we want to fall back to more structure and being told what to do.
A great example of this is when a team’s stand-ups start becoming mundane, overrun their time boxes, and team members don’t show up. So what happens is we come up with a template for the team to keep up with for daily stand-ups, as well as establish a set of metrics we answer to during the stand-up. And of course, this just becomes one more thing for a team member to keep track of, as well as an unintentional mechanism of command-and-control.
As an ex-Director/Manager, I often wanted to step in and help — and I usually would come up with a template and/or some hard-prescribed structure and tell the team to follow it. I wanted to help, and that’s what Managers genuinely want to do. But I was quickly put in my place when one of my team members said, “Let us figure it out; it’s our problem.” I gave guidance and advice, but otherwise I got out of the way. I let the team come up with how they were going to make their meetings more effective. And at the end of the day, they simply looked at the frameworks themselves and decided to more closely follow the existing framework guidelines — e.g., keep stand-ups to 15 minutes and stick to the script, then allow the time remaining to become open-space troubleshooting time.
At the end of the day, remember that more process does not equal more better. Rely on the team to solve problems, over-instituting process and templates to solve problems. I think I’ve heard this before somewhere …
You may have a well-articulated, strategic roadmap BUT how, when and what value you deliver against that roadmap can fluctuate. A benefit of iterative delivery and deliberate learning cycles is that product teams can tweak or radically change output based on what is discovered. Build, measure, learn and change.
A high-performing product team will stop working on ideas when there is evidence that the value is not as high as projected, and start testing new ideas. Embracing this agility means recognizing change early and adjusting often. Any predictions you made one sprint ago should be questioned. Roadmaps created one quarter ago should be questioned. So how can we get better at encouraging and responding to change vs. the extreme: adhering to a fixed, top-down plan?
- Ensure visibility into product team initiatives, and that they roll up to strategic initiatives and roadmaps – as a tool to continuously align the organization from strategic initiative to team focus and back up the chain.
- Build flexible roadmaps that are outcome-driven while promoting change and innovation.
- Plan continuously at all levels in the organization, align, re-plan and align again. Quarterly planning may be too late to be effective.
- Consider roadmap changes regularly. Don’t miss an opportunity to pivot early.
- Recognize that a forecast may only be relevant for a moment in time, based only on today’s assumptions. Review, communicate and adjust often. Or don’t forecast.
Hopefully your organization has this problem, where your teams are learning and delivering value beyond what was planned for, despite being less predictable about it. If not, it may be that your organization has a fairly static plan based on what the teams can deliver, based on the current constraints.
Organizations like these that “go agile” recognize that stable teams and iterative delivery can produce output more predictably… perhaps stabilizing roadmaps. But, competitive value comes when we are able to respond to what we learn, change direction, and produce valuable differentiators which we could not have predicted. While these outcomes are less predictable, agile enterprise-level planning needs to be just as dynamic as the product teams in order to organizationally align and deliver against what is measured and learned.
StandUp is a cornerstone of any agile practice. It runs like a well-oiled machine at most agile shops. You get the talking stick (or ball, or the coolest piece of swag from your last agile conference (for the record, it was the V1 ‘Do Me Daily’ t-shirt), and you quickly and very professionally (even though you’re wearing cutoffs and flip flops) speed-speak your status so you can get back to your console and start slinging code asap:
“Yesterday I made the changes to the Uber-Widget that Bob asked for, and today I’ll be working with Matthew to get that styled up and looking good. I may run into an impediment if Matthew isn’t available. When that’s complete, I’ll be ready to plan the next story.”
Then you pass the talking stick to the next team member like you’re shooting a 3-pointer (cuz you’re cool like that and it’s NBA playoffs time). And so it goes around the circle until the ScrumMaster gets the stick in his hot little hands and tells everyone Matthew is out sick so let’s hold off on the Uber-Widget styling and jump right into the next story.
That’s how it’s supposed to work, right? Tell the team what you’ve done, what you’re currently working on, and any impediments you’re facing. The ScrumMaster then leads a discussion to resolve any impediments so that the team can maintain forward progress.
And it does work! That’s the beauty of it – excellence only comes with practice, and we get to practice standup every day. E-V-E-R-Y damn day. So we’re pretty damn good at it.
However, even the most rigid training schedule needs a shake-up now and then. Here at VersionOne, we have the occasional StandAround instead of a StandUp. StandAround usually happens on a gray, rainy day when half the team is out sick. You know it’s going to be a StandAround when the scheduled StandUp music gets through an entire song before the team manages to mosey over to the meeting area. Once everyone is together, blowing on their fresh coffee, idle chatter bubbles up here and there. Instead of the git-r-done vibe of StandUp, StandAround has a laid-back, get-to-know-’ya cachet. Team members catch up, crack a few jokes, and then get on with their day.
Keeping the team healthy is just as important as forward progress. So every now and then, have a StandAround. Let it happen. It’s OK!
I’ve been reading a lot lately about the concept of enterprise agile and how the heck to do it. Agile development roots point to a very team-centric concept. And its success has piqued interest from other teams, other business units, and larger enterprises when it comes to scaling agile faster, better and easier. In fact, more than 61% of VersionOne customers recently said they’re in the process of scaling agile across their organizations.
The potential of agile is awesome… but it can be difficult to successfully adopt. For people who have been there, they can tell you it’s hard…but worth it. If you’re planning an enterprise agile project and worry what growing pains you’ll run into, you’re not alone.
One highly effective approach I encourage you to look into is the concept of Scaled Agile Framework (SAFe). Ever heard of it? Dean Leffingwell, a renowned methodologist, coach, entrepreneur and author is giving a presentation on SAFe which you won’t want to miss:
Part I – Monday, May 13th at 12 Noon EDT
Join Dean Leffingwell for an overview of SAFe, a publicly-accessible knowledge base of proven lean and agile practices for enterprise-class software development. You’ll learn how SAFe enables you to:
- Deliver business results that scale
- Keep your development system – and enterprise – lean
- Increase responsiveness to rapidly changing market needs
Part II – Wednesday, May 22th at 12 Noon EDT
Join us for a look into how VersionOne supports SAFe and helps accelerate adoption of enterprise agile. Andy Powell, Product Evangelist and Scaled Agile Framework Program Consultant, along with Lee Cunningham, Enterprise Agile Coach, will focus predominantly on the Portfolio and Program levels of SAFe and will demonstrate how VersionOne provides:
- Metrics that enable your business leadership to make more informed decisions
- Visualizations to help program managers pinpoint areas of risk
- Collaboration capabilities to capture the “why” behind key decisions
I recently read the excellent and fascinating book “The Power of Habit” by Charles Duhigg. The book doesn’t only cover habits of individuals, but also habits of communities and organizations. Reading it reminded me of a conversation I had with our CEO, Robert Holler about V-Days.
V-Day is our monthly company-wide gathering that brings everybody together to keep them in the loop as well as connected to each other. Family members, friends, and even job candidates are also invited. V-Day starts with lunch in the Game Room, continues with a break for everybody, reunites everybody for short presentations by each department about the last month, and usually ends with a “keynote” address by Robert.
- We generally feel informed about what is going on in the company
- We enjoy hearing the update rhymes Maggie finds the time to create about the Services department.
- We get to know new (and old) team members during lunch and the break
- We meet spouses and kids of co-workers, and they get to see where their parents go during the day
- We build shared memories
So what is the link between V-Days and The Power of Habit? I’m abbreviating a bit here, but you can build a habit by deciding on a certain routine that follows a certain cue – and practice it until it starts to be a habit. So non-habitual routines can turn into habits. However, they can also spawn additional habits by creating scheduled events that foster certain routines. For creating certain organizational behavior or company culture, the trick is figuring out which habits are most prominent in them, and which corporate event would most encourage those habits.
V-Days are a great example of that elusive “habit-fostering event.” They support three of the most prominent company habits – which also happen to be quintessential to agile teams: (1) Remember and share information that concerns others, (2) Interact with other people in VersionOne on a personal level as well as a professional one, and (3) Remember to acknowledge great work getting done.
I asked Robert if he had read the book, but he had not. Nevertheless, V-Day makes for a great illustration of many of Duhigg’s points, and IMHO a company-wide regular and fun get-together like this is one more secret to building agile culture.
At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.
- Agile Manifesto (agilemanifesto.org)
In case you weren’t aware, this is the 12th Principle of the Agile Manifesto and it is often translated into “inspect & adapt.” Of the 12 principles, this is definitely the one to which everyone can easily relate. The team should look at what they are doing, look at how they are doing, and adjust. This is primarily for the team, and I would argue that it’s mostly about the process (and maybe people stuff), but it could be around the product and/or project if we are doing this in respect to a specific release, or even the outcome of the sprint.
With Scrum, there is a ceremony (a.k.a. meeting) called a Retrospective. Other frameworks and processes have adopted the spirit of this meeting, and there are a bunch of creative ways to conduct the Retrospective. If they are kept fairly informal, transparent, and candid, then they can be hugely valuable — especially when they are actionable.
But this article is not about the Retrospective. Instead, it’s about the terms and maybe even the way we speak of the concept “inspect.”inspect. v. To examine critically or carefully; especially, to search out problems or determine condition; to scrutinize.
If you’re development shop is worth its salt, then you are constantly inspecting. Let’s face it, the feedback loop with following iterative development, using continuous integration, employing automated testing, and on a cross-functional team is really tight. This means that we are constantly re-digesting information from our feedback loop — so inspection is constant.
I propose this… instead of “Inspect and Adapt,” shouldn’t we “Innovate and Adapt?” Now I cannot take credit for this change of terms. I was driving home one day from the office and I heard a post-season interview with the Atlanta Falcons’ head coach Mike Smith. He was talking about the fact that the team has reviewed all the tape from the year and now it’s time to innovate and adapt. He went on to say that seeing one’s issues and/or challenges is not enough; they have to find ways to beat the competition and be better — that requires innovation.innovate. v. To alter; to change into something new.
So instead of simply looking and digesting, let’s imagine and innovate. Once we innovate, we adapt the new ideas to our team; we continue inspecting our feedback loops; and we continue our innovation.
Sometimes when you innovate, you make mistakes. It is best to admit them quick, and get on with improving your other innovations.
- Steve Jobs
I got an email this morning from our Community Manager listing all the agile events we’re doing this spring and wow – we’re gonna be busy! Scope out the list…
Is one of these events in your area? Come out and see us. Don’t give a crap? Share this list with someone who might:
AgilePalooza Twin Cities. Private day @ Target on 4/11. Public day on 4/12. http://agilepalooza.com/mn2013/
Mile High Agile: Denver, CO. 4/19 http://milehighagile2013.agiledenver.org/
PMI Region 6: St. Louis, MO. 4/19 – 4/21 http://www.stlpmi.org/
LeanKanban 2013: Chicago, IL. 4/29 – 5/1 http://lkna.leankanban.com/
PMI Nashville: Nashville, TN. 4/29 – 4/30
Project Management Symposium: Innovating the Future. http://www.pminashville.org/downloads/newsletter/doc_download/84-symposium-flier-with-schedule
PMI Augusta: Augusta, GA. 5/2 – 5/4
PMI Region 14 Leadership Conference. TBA.
Kansas City Developers Conference. 5/3 – 5/5. Kansas City, MO http://kcdc.info/
Scrum Gathering Las Vegas. 5/6 – 5/8. http://www.scrumalliance.org/events/610-las-vegas-
AgilePalooza Seattle. Private day: TBD — 5/16. Public day: 5/17 Seattle, WA http://www.agilepalooza.com
Gartner PPM Summit. 5/20 -5/22 Washington, DC http://www.gartner.com/technology/summits/na/program-management/
Path to Agility. 5/22 and 5/23. Columbus, OH. http://www.thepathtoagility.com/
ADP West. 6/3 – 6/7. Las Vegas, NV. http://adc-bsc-west.techwell.com/
Catch a complete list of all agile community events or list your own event at AgileSherpa.org.
The last year has proven to be tumultuous for many companies and especially enterprise IT organizations. Interestingly, the challenges are not too different from what has existed for some time; a combination of delayed projects, failed attempts at introducing change and cost cutting pressure. These ongoing challenges have forced many of these organizations to put the brakes on when it comes to spending in areas that carry big names such as “enterprise agility” or “transformation.”
The added pressure of defining “innovation” has meant that some companies are masking the requirements under more commonly accepted spending areas like digital and mobile, all for the sake of being assured funding will happen. Yet, the requirement to dramatically improve the end-to-end flow of the organization still exists and regardless of what names we assign to programs in order to gain funding, we will still need to fix the real problem of how we prioritize value in the business.
Would you agree that too much emphasis exists on labels such as agile, lean, transformation and so forth? Unfortunately, agility is not a budget line item that gets defined and allocated during the annual budgeting rounds. People struggle with defining what it means for them and their organization and ultimately barriers exist to change. If we can’t allocate a number to agility then how else do we get it started apart from introducing tools and methodologies? One way is to get the decision makers and key influencers in the organization to talk openly about the views they have on topics like change and agility. To use a common quip, recognition is the first step to recovery.
So what are some of the common challenges preventing a more deliberate approach to change and that impact agility becoming more prominent in the funding discussion?
- Prioritization is still a problem
- The interesting thing is that most people perceive the prioritization problem to be a resource problem; i.e., we don’t have enough people. This is often compounded by their suppliers telling them it’s a resource problem, for obvious reasons. It is, however, more often a structural problem and political challenge within the organization.
- Capability and competency is a challenge
- Organizations recognize the need to invest in their people and bring them up to speed on modern ways of working
- There also appears to be a shift toward doing more work internally – the long-term dependence on large suppliers combined with problematic outcomes is causing many organizations to work with highly skilled niche players who bring core competencies, but can also work alongside their staff to mentor and pass on skills
- The reality of single-skilled people in siloed organizations is causing problems. Organizations are struggling with how to leverage learning across the wider organization and how to best invest in this is becoming increasingly difficult. In the world of agile, for example, learning how to best apply practices has been limited to short-term classes that don’t yield learning that sticks. With the introduction of work-based learning in the agile space, this changes the landscape and solves this problem for companies and individuals.
- Organizations are moving away from ‘big project’ mentality
- There appears to be little to no appetite for massive big program investments. While the interest to deliver software projects incrementally has been in play for some time and has proven effective, the same interest now exists in understanding how to deliver change incrementally across the wider organization.
- The common pain point here is how do you make incremental change when trying to do system replacements. How do you know and define the appetite for change and do it in a manner that keeps people motivated and engaged and not overwhelmed. There is a real desire to learn how to do this within many organization but for many, years of doing things a particular way prevent them from going forward.
You will likely have other challenges that are equally as prominent to your specific situation so these three are really to get the conversation stirring. It is these types of challenges that have made it harder for companies to be courageous on doing a wider transformation, especially where the application of new thinking makes sense. As it relates to enterprise agility or agile transformation, the trepidation and hesitation often relates to these three areas:
- Funding model
- The overall approach to funding, budget allocation and IT being seen as a cost center.
- The annual funding cycle drives the exact opposite behavior than an agile approach needs; i.e., it looks for certainty.
- The funding approach appears to be the sacred cow in most organizations.
- Change is still a big word
- A general apathy toward change still exists – this apathy is often driven by the fear of disrupting things too much; again, the appetite for change is what is not often defined
- A concern in some organizations that change is being driven from, or perceived to be driven from, the IT department. The general view is that IT departments do need to change, but are there to serve the business. In several cases the business does believe they need to change to support IT.
- Resource Management
- Balancing the cost/investment of staff from both a permanent and contractor/supplier perspective is still a challenge. For example, the inability to view spend on full-time staff as ‘actual spend’ is a common area of neglect.
- Organizations need, at the very least, to look at the opportunity cost of their FTE spend and then identify where the real gaps in competency and skills exist. From there, it becomes a productive exercise in determining how to best fill those gaps with outside skills and/or learning.
Let’s bottom-line this discussion. Enterprise agility is an outcome not a budget line item. That said, to get to that outcome, companies can take specific actions that can be funded like any other program effort, yet with very different results.
Contributions to this article were made by my colleague, Brian Hanly