Taking the Plunge

It's that time of year again.  You know what I mean.  The time of year when you try to find your project team and ask yourself, "Why did I commit to a deadline between Thanksgiving and New Year's Eve?"

For those of you who don't work with US teams, you probably have a similar experience around other holidays.  I worked with a team located in Europe and found that August was not a good time for deadlines.  Golden week, in China, is not the most productive time, either.  Fortunately,we can account for these events in our schedule.

I'm finding that a bigger challenge is trying to run a distributed agile team with three sets of holidays.  The running joke is that Argentina is always on holiday and Peru never gets a holiday.  As long as the developers don't have urgent questions for the product owners, over US holidays, their productivity is not greatly affected.  It's not actually hard, it just slows the work down, and we need to coordinate our release dates a little more carefully.

I enjoy what I do at work, and I also enjoy being able to step away from it, over the holidays, and focus on things other than project management.  That's where I'm at, this year.  Unlike the person in the video below, when I step away from work for the holidays, project management the last thing I want to think about (except for my blog, of course). You don't have to watch the video; it's just six minutes of someone's preparation for and execution of Thanksgiving, shown in Jira. Masochist.

An Agile Thanksgiving with Jira

If this is you and your holidays, I hope it's by choice.  If I had to use project planning software to schedule my vacation, I would look forward to going back to work so that I could take a break.  My only plan for the long weekend about to start is to smoke a turkey.  Deboning it is a chore, but it is soooo worth it.

Whenever your holidays are, I hope you get to enjoy some combination of good food, good friends, family, and doing things you enjoy.

I thought I'd take a moment and think about something other than election coverage.

I'm not sure if it's cause, effect, or altogether something else, but optimism and vacuums seem to go hand in hand.  Think about your last project, for a moment. How accurate were the estimates given in the early stages of the project? If you have even a little experience in project management, you knew they weren't going to be accurate, but you may not have identified all of the reasons why.

The obvious reason is that the earlier it is in a project, the less you know about the project.  A factor that often gets overlooked is everything else going on in your organization.  You can know that it will take six months to complete the project... if that's all anybody did.  How long will it take when you account for everything else going on?  Planning projects in a vacuum happens all too often, and it results in optimism about how much work an organization can complete in a given amount of time.

We're all familiar with the concepts of effort and duration, I hope.  If you want to know when a task can be completed, you need to know how many hours it will take for the assignee to complete the work, but you don't stop there.  Next, you need to determine how many days it will take for the assignee to find the time to perform the work. I'm sure I'm not the only project manager who has seen a task that only required two hours of effort take more than two days to complete, for legitimate reasons.

Tasks are to individuals like projects are to organizations. There can be unknowns that make it difficult to estimate the "organizational effort" of a project. All project managers deal with this. We also need to understand the "organizational duration” of our project, taking into account the other projects and activities (priorities) our organization is pursuing that could affect our schedule.

If you think that this is starting to sound like portfolio management, you might be right. If your company is effectively managing a portfolio of projects, instead of running multiple silos of projects that, surprisingly overlap, you are doing better than many other companies.  This is the vacuum and optimism I'm talking about. When we plan our projects in a vacuum, our estimates are basically blindly optimistic.

What can we do about this situation?

Don't run out and buy portfolio management software. Throwing a tool at a problem, without at least minimal analysis, just creates another way to fail.  There are three aspects of problem solving that need to be addressed, in order. They are:

1) people

2) processes

3) tools

You won't solve the problems associated with optimism and vacuum-based estimates without the right people.  You might be able to deal with this approach internally, but don't ignore the value of a third party facilitator or coach to help guide the change. 

As you're getting the right people involved, make sure you all agree on the problem that you are trying to solve, then start identifying gaps in your current processes. From there, you can identify any additional processes and tools you may need.

Simple, right? Okay, maybe not as simple as I make it sound.  You may not need a robust portfolio management system. Alternatively, you may need one, but not be in a position to implement one.  Your mission, should you choose to accept it, is to gather the right people and figure out the best way for your organization to break away from optimism and vacuums.

When everything is a priority, nothing is a priority.

I've been saying that for over a decade and had no idea it was an actual quote, by Simon Fulleringer.  I'm not claiming it was me.  I just thought it was one of those things that was inherently true and often overlooked.  It's also a sign that priorities probably need to be addressed.  That is where I find myself.

I've been trying to do too many things for a while, now, and not gotten very far on any of them.  The impact to my blog is that I am going to start posting every two weeks, instead of weekly.  As I will also be cutting back on other activities and using my time more effectively, or trying to, anyway, this should give me time to finish one of the books I've been planning to post on  - The Agility Shift. 

My plan is to post more content about making an agile transformation, not just about adopting agile practices.  I'll also post about some of the personal projects I am working on, and will continue to give updates on my agile team, at work.  And, of course, anything else project management related that comes to mind.

Speaking of my team, we had our first formal retrospective, today.  One of the things that was identified was how valuable the communications tools we are using have been.  We've got developers in three different countries, but they are in regular contact with each other in spite of time differences.

The team is all on the same page with regards to improving our definition of ready.  We're going to make a conscious effort to examine our stories and determine when more detail is needed in the story before putting it into the sprint, and when we just need the appropriate conversations to take place.  There needs to be enough detail to estimate the work without BDUF - big design up front.  The conversation is key.

Back to priorities.  It's not that you're not important, but I have other priorities that I need to take care of tonight.  See ya' in a couple of weeks!

You might recall previous posts where I stated that making the transition to Agile can be challenging?  Well, this is where I give a personal example of my experience as the company I work for makes an agile transformation.

I was recently asked to be ScrumMaster over a mobile project.  Okay, it would probably be more accurate to call the project a program, and to call myself an agile coach, but that is not how it was presented.  Our framework is Scrum-like, but given the following conditions, I can't really call it by-the-book Scrum.  However, that does not mean we're not going to make it as Agile as possible.

• Six developers; two local, four off-shore.
• 4 product owners
• iOS and Android versions of each product.  Would that be four products, or eight?
• These are ongoing maintenance efforts

I joined the project team on the last day of the Sprint.  It was a 45 minute meeting where three different sprint backlogs were reviewed and two features were demoed (is that a word?).  A sprint retrospective was not held.

I know, some of you are probably ready to tell me how agile we're not and how I need to fix things, quickly, but would that be in the spirit of agile?

Currently, we are meeting 3 days a week for 30 minutes to an hour, on a video call with developers in three different locations.  Sprint planning is on the fly, and sprint retrospectives have not been done in a while.  Among the areas where I have identified that we can make improvements are:

• A consolidated story board and sprint backlog
• Potential changes to the meeting schedule
• A unified workflow across all products
• Product roadmaps
• Standard definitions for the following, across all products, since the developers all work on more than one product
  • Definition of Ready
  • Completion Criteria
  • Definition of Done

I've created a consolidated story board and sprint backlog, and we've started talking about the other items.  I intend to have a more formal discussion about these items during the retrospective, next week.  I could try to force changes in all of these areas, at once, but I think that would do more damage than good, not to mention that the team would spend more time on process improvement than development.  The team was getting work done before I became the scrum master agile coach.  Some people might have thought things were a little rough before, but change doesn't guarantee they won't continue to be rough; they'll just be different.

I am aware that there are times when it is best to just rip off the bandage, but my intent is to treat my team like a high performing team.  There are changes that can be made, sure.  Scrum has a process for fine tuning team processes, called the retrospective.  I will use this tool to make recommendations to the team, as well as encouraging them to identify areas where we can improve, and then let them decide the changes they want to make, determine the priority of the changes, and establish their own cadence in making those changes.  The collective team may have better solutions than I could come up with on my own.

I'm ready for this adventure and look forward to working with my team.  I'll share more as they become the high performing team that I know they can be.

Let me preface this by saying that this is not the introduction to 10+ posts on the Flavors of the Waterfall methodology.  It's one post with the intent to explore Waterfall's origins.

Why?  I've lost track of the number of times I've heard (or read) Agile evangelists offer a proscriptive definition of Waterfall and then blame the process for failed projects.  They almost make you think that every Waterfall project fails.  So, what happened before Agile, and what, exactly, is Waterfall?

The most popular theory that I can find is that Waterfall came from a paper written by Dr. Winston W. Royce, titled "Managing the Development of Large Software Systems," published in 1970.  Dr. Royce never named a methodology Waterfall, and in his paper he gives the impression that he thinks that there is more than one approach to software development.

The first approach is described as the "…two essential steps common to all computer program developments, regardless of size or complexity…" analysis and development.  If the program being developed is small enough, this is all that is needed.  Hmmm.  This doesn't seem highly proscriptive, and could be argued to be the foundation for iterative development (although a bit of a stretch).  This must not be Waterfall.

The second approach, specifically for developing large computer programs for delivery to a customer, is described with the following phases:

• System Requirements
• Software Requirements
• Analysis
• Program Design
• Coding
• Testing
• Operations

Now that looks like Waterfall!

But Dr. Royce didn't stop there.  He went on to explain that each of these phases has an iterative relationship with the phase immediately preceding it.  What this means is that once System Requirements are complete, it is possible that something could be found during Software Requirements that requires you to go back to System Requirements, and so on through the phases.  That does not sound like the Waterfall that the Agile evangelists complain about. 

He didn't express any concerns with the iterative relationship between sequential steps.  The concern he expressed was that this iterative relationship had the potential to jump back multiple phases, resulting in significant delays because you couldn't skip back to where you came from; you had to go through the phases in sequence to get back to where you were.  This sounds more like the Waterfall that so many have come to know and dislike.

This is also the first two pages of the paper.  The rest of the paper consists of diagrams and steps to eliminate the risks inherent in the process.  These steps are:

• Introduce preliminary program design before analysis
• Document the design.  Dr. Royce was a firm believer in documentation, and lots of it.  Yes, we're back on the Waterfall path, again.  However, he is not recommending documentation for the sake of documentation.  He just feels that a large software development project requires a lot of documentation, for very specific purposes.
• Do it twice.  Run a smaller scale pilot, in a shorter timeframe, to simulate the process and identify then resolve problems before running the full project.  And, yes, this is, counterintuitively, done before the next step…
• Plan, control, and monitor testing. 
• The "last" step, although it is not so much a sequential step as a set of steps throughout the project, is to involve the customer.  Three formal points for identifying the customer are identified, 1) during the Preliminary Software Review, held between the Preliminary Program Design and Analysis, 2) during the Critical Software Review, held between Program Design and Coding, and 3) during the Final Software Acceptance Review, held after Testing and before moving into Production.  The expressed purpose for involving the customer is to gain commitment; giving the developer free rein is a recipe for failure.

I'll be honest, I have used similar phases but, in 15 years managing projects, I have never done it exactly like this.  Does that mean I wasn't using Waterfall, because I wasn’t doing it right?

No.  This process potentially provides a foundation for both Agile and modern Waterfall.  On the Agile side, there is iterative work and maintaining a close relationship with the customer.  On the Waterfall side, there are sequential phases and lots of documentation.

This process could take a lot of time.  Keep in mind that Dr. Royce never described a process for a medium sized development project.  The process he described is intended for a large software project, which could take a lot of time even if you used Agile, instead.  Agile does not guarantee faster delivery of a completed project, it attempts to deliver useable features faster.  Agile may actually take longer than Waterfall on a large project, with the tradeoff being that what is delivered has a higher likelihood of being useful (and different from what was designed at the beginning of the project).

So, what is Waterfall, today, 46 years after Dr. Royce's paper was published?  It's still sequential, mostly.  It can still require a lot of documentation, but each project should be looked at to determine how the phases should interact and what the right level of documentation is.  The area where Waterfall struggles the most is an area that would cause Agile to fail, as well.  Customer involvement.  Agile prescribes customer involvement. Waterfall apparently does, too, according to Dr. Royce.  It's just not always implemented that way.  When an Agile evangelist blames Waterfall for project failure, that person is removing accountability from the people who ran the process that failed. The project that failed may be one that would have been better served by Agile, but it may also be that the process needs to be adjusted and the people running the process need to learn from their mistakes.