Caution: Agile Surface May be Hot

From the Requirements Blog
by
Effective requirements collection, management and traceability plus smart PM practices equals project success.

About this Blog

RSS

Recent Posts

Caution: Agile Surface May be Hot

Organizational Change Management: The Most Critical Requirement of All!

Rethink Requirements: The Natural Language Processing Approach

Quality - Consider it in all Knowledge Areas!

Don't get COT[s] by your package!



Most people are familiar with the Agile Manifesto and its Principles developed in 2001 by seventeen people engaged in the IT (software) industry. Requirements take the form of a Vision Statement, Epics, Features and User Stories. Agile is much loved by those who like simplicity (does that include you?), high user involvement, high visibility of work to be done and work in progress, continuous team collaboration, self-managed teams, minimal documentation, face to face communication and very fast turnaround of deliverables in pre-planned, fixed iterations, creating a project cadence that raises expectations for frequent showcasing of completed work.

You may concur that sixteen years is a very long time in the software industry. I suspect Agile approaches are already baked into many methods. There has been talk and action for a few years now to make Agile scalable to deal with large projects, and hybrid methodologies have appeared that take advantage of the best of Agile and the best of traditional and iterative approaches. I believe there is wisdom in this thinking - something about not throwing out the baby with the bath water.

But Agile was clearly meant for software projects. Can it be used in non-IT projects?

A recent rather unscientific poll I added here seems to prove that one of the Agile frameworks, Scrum, is sufficiently pliable that it can be used outside the software industry. About 1/3 of the respondents (OK - only 21 responded, but you can change that), said they had used it on non-IT projects already and another third said they were planning to do so.  And there are plenty of industry posts about this. One of which I am particularly fond is by InfoQ, where they highlight some of the challenges with using Scrum on non-IT projects and provide some clues about how to convert from technical software terms to business terms.

I believe any project can benefit from Scrum methods. Who would not want to reap the benefits of high visibility of work to be done, progress being made, frequent communication, an engaged team and client, and work being presented in weeks instead of months or years? Wouldn't everyone want work to be broken down into chewable chunks when it is possible to do so? Remember what our friend Albert said: "If you can't explain it simply, you don't understand it well enough."

Maybe it is time to create an Agile Manifesto for non-IT business projects. What might it look like? I'll go out on a limb here to take a stab at it:

  • Individuals and interactions over complicated methods and software tools
  • Completed deliverables over comprehensive documentation
  • Customer collaboration over contract negotiation
  • Responding to change over following a plan

Okay - so what changed? Not a lot, really. I changed "processes" to "complicated methods" and "tools" to "software tools" in the first line; "software" to "deliverables" in the second line; and I didn't change the last two at all.

I chose the word deliverables since it is generic and could represent a process, a document, a change in the thinking of a group of people, a new product line - you get it - a business-focused item.

So we might think much of the change would be in the Agile Principles. As they say, the devil is in the detail, which is what the principles start to address. Let's take a shot at modifying those to be more business-focused and less software-focused:

  • Our highest priority is to satisfy the customer through early and continuous delivery of usable deliverables.
  • Welcome changing requirements, even late in deliverable development. Agile processes harness change for the customer's competitive advantage.
  • Produce deliverables frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.
  • Business people, subject matter experts and deliverable-producers must work together daily throughout the project.
  • Build projects around motivated individuals.  Give them the environment and support they need, and trust them to get the job done.
  • The most efficient and effective method of conveying information to and within a project team is face-to-face conversation.
  • Credible and usable deliverables are the primary measure of progress.
  • Agile processes promote a sustainable pace. The business people and the team should be able to maintain a constant pace indefinitely.
  • Continuous attention to excellence and good deliverable design enhances agility.
  • Simplicity--the art of maximizing the amount of work not done--is essential.
  • The best work emerges from self-organizing teams.
  • At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.

Once again, not a lot has changed. Software becomes deliverables and some of the more technical terms are converted to more business-friendly terms.

Have you used Scrum on non-IT projects? How did it work for you? Did your business users embrace it? Was the high visibility too much for them? Did the team manage themselves? How was the business user interaction? And perhaps most importantly, were business requirements satisfied?

Weigh in with your thoughts!

Posted on: May 25, 2017 10:53 AM | Permalink

Comments (13)

Please login or join to subscribe to this item
I have mixed feelings about Scrum - I like the frequent interactions and responding to change. I feel it does make a project more dynamic. The downside for a busy PM is that it also requires more reporting, more meetings and more time. As more and more projects that I work on incorporate scrum I am hoping to learn more of the benefits it provides. Thank you for your post it makes me more optimistic about Scrum.

Thanks, Agile methodologies is what is imposed today in the world.

You are most welcome, Jennifer and thanks for your kind comments. I have some comments about reporting on Scrum projects as it relates to the sadly absent PM role in Scrum:

- PMs are required on Scrum projects, regardless of what our friends who invented Scrum say about project roles.

- The Scrum Master is not the PM and vice versa. These are two different jobs and they should be done by the same person only when resources are scarce and the project is small.

- Reporting outside the development team is still required. You really can't point to a burndown chart or a card wall and say to an executive VP "Login here. There you go - we don't do reports anymore."

- Scrum does a poor job of addressing many traditional items a PM must report and track because the client demands it, such as the financials of the project, estimates to complete and so on. A PM is still required to this.

But here are what I think are the advantages and reasons PM reports ought to be easier with Scrum:

- The PM doesn't have to get status reports to know the state of the project. It is all there in the burndown charts and card walls - it only needs to be translated into whatever form of reporting is required by the client.

- Burndown charts driven by the movement of cards by team members should be accurate and up to date. No more waiting for reports as long as the team is disciplined enough to manage their own cards. And if they are not, PMs must resist the temptation to move cards for them. Same for card walls.

- Some clients can be trained to interpret burndown charts and card walls. Just not all of them. So traditional reports will likely still be required.

Just a few slightly under-developed thoughts that come to mind...

You are welcome, Eduin. "[insert newest methodology name here] or die" is not a great rallying cry, for sure. I think we must always be careful to keep the hard lessons of the past and meld them with new methodological approaches - that hybrid approach I mentioned.

Thank you, Mike. My experience is in IT related fields only. I have been exposed to both approaches, traditional and scrum. In the end, the goal is the same, provide the product to the customer that solves their problem. Agile allows greater flexibility to allow that to happen, which I like, however, many times, the vision and requirements are clear, so plan-driven works great there.

I have worked only in IT domain. Agile is dynamic in nature and provide early feedback. Agile is most suitable for projects having very less defined scope and more to be expanded over the period. Agile is also suitable for complex projects.

Agree, Andrew, that if things are very clear, a plan-driven, or as PMI calls it, a predictive approach may be best. And even then, I believe some aspects of Scrum can still be used, especially those related to team communication and high visibility.

Yes Sonali - Agile and change certainly go hand in hand. A hybrid approach can also work even when scope is well defined, especially if there are other unknowns in the project.

Thank you both for your comments.

I deal mostly with traditional projects, but the flexibility that Scrum and Agile have to embrace change has an appeal for me. Planned work must be flexible and able to embrace change as it is encountered; this can be problematic with traditional approaches and inflexible environments. I am hopeful that continued growth and development in these areas will produce new benefits in the application of hybrid methodology.

Yes, expecting change seems to be much closer to reality doesn't it, Renee? We can only hope that those sponsoring projects come to expect it too.

If you can't explain it simply, you don't understand it well enough,perfect !

Thanks for sharing

Thanks...easy way to understand.

I really thank you all for your valued insights.I wondering if there are any known strict no-go areas for Agile in non-IT projects.It seems to me no matter the project type Agile techniques will always come in handy.

Please Login/Register to leave a comment.

ADVERTISEMENTS

I don't have a good apartment for an intervention. The furniture, it's very non-confrontational.

- Jerry Seinfeld

ADVERTISEMENT

Sponsors

Vendor Events

See all Vendor Events