Taking the Plunge

Nine years ago, when I signed up for the CSM class, I went into it thinking, "I'm going to learn how to do Scrum, at work."     I was partially correct, and I wasn't alone.  As mentioned in my last post, I don't have figures for how many people take a Scrum (or other flavor of Agile) class, expecting to know how to make it work at their company afterward, but the more people I talk to about this, the more people I find who experienced the same thing; Scrum certification classes focus on using Scrum, not on how to get the rest of your company to use Scrum.  Admittedly, it is a small group.

If you search the web for how to become Agile, you will get a lot of different results.  Some people say being Agile is more about your state of mind than your skills.  Others attempt to point out that it's not really agile to strictly adhere to one project management/development approach.  A lot of online information about becoming Agile isn't that different from the CSM and CSPO training classes, in that they focus on steps to use a framework or methodology, as opposed to how to successfully transition your company to using Agile processes, which is where the pain point really lies.  It can be discouraging to want to do something that can be a game changer if you are the only willing to do it.  It's hard enough when you have support for the change.

Don't get me wrong, I'm not saying these are useless resources.  Some are very good.  A couple that I found, this week, that I like are:

• The Scrum Kickoff Planner
• The Scrum Checklist

But, it seems like if you want to learn how to transition your company to using a flavor of Agile, you have to hire a consultant/company to take you through the process. This is not necessarily a bad thing, but it could be difficult to convince company leadership and get approval for the budget.  Perhaps one of the biggest reasons that it is difficult to find meaningful information on transitioning a company to Agile, freely available, is that there is no one-size-fits-all approach to doing so.  I'll withhold cynical comments about it being a source of income for some companies.

Some sources say, "Just get started."  In a sense, they are right.  If you spend your time worried that you won't be able to do it, you'll be right.  So, how do you get started?  I wish there was a simple answer.  If all your company does is develop one piece of software for retail sale, making the transition to Agile is less complicated than it might be for a company that has multiple product lines, and multiple sales channels, in multiple global markets, with separate, yet connected, back end systems that all need regular development and upgrades.

In the spirit of "just get started," are you able to run an experiment?  Can you pick a team, get them trained, and run an Agile project for one of your products?  If you're successful, you potentially have champions for taking this to other groups in the company.  I'm not saying that this is the best approach, but it's one way to demonstrate value, if you succeed.  I've said it before; transitioning to Agile is organizational change.  It's risky.  It's bumpy.  It's hard.  If you want to succeed, key ingredients are either adding value that others value (not just you), or solving a problem that is causing others significant pain. 

You could start top down - convince the executives that Agile is the right way to go and then drive it out to the organization - but I still recommend starting small.  A big bang approach might work, but it could also magnify a single issue that is experienced by multiple teams.  You need to make sure that all affected understand that it is a learning process, not an instant fix.

You also need to make sure that everyone understands their part.  There may only be a few roles in Scrum, but you can't run a business with just a Scrum team.  At least, not a large business.  There are other people who may not play a direct role in a Sprint, but they are affected by processes and outcomes and may have a voice in whether or not you continue to use your particular flavor of Agile.

Considering all of the above factors, this is probably why companies use a third party to help with the transition.  Even using a consultant is not a guarantee of success, but not because Agile doesn't work.  Many companies have demonstrated that Agile works for them.  The trainer for my CSM class related a story about a company he was working with.  There were certain changes that he told them they needed to make in order to use Scrum effectively.  They refused to make the changes.  After considerable discussion, the decision was made to terminate the transition. 

This speaks to why I feel that more could be done to educate companies, not just individuals, on what it takes to be successful using a flavor of Agile.  If the company leadership is not committed to making changes to how their company functions (or dysfunctions) and follow agile practices, the transition will eventually fail.  Chances are, when this happens, the failure will be blamed on Agile, not on the inability of the company to change.  The right mindset is an important part of making the transition.

I like the approach Mountain Goat Software takes to determining when to use Agile.  It's not a question of whether or not your company can use Agile (although this is a good place to start), it's which projects are suited for Agile.  A company doesn't have to adopt the same agile processes across the entire organization.  It may make sense for a company to have some dedicated Agile teams while the rest of the company uses other approaches.

I wish I could give a simple, definitive response to "How to transition to [pick a flavor of Agile]", and not just because of potential financial implications.  It's not simple, but it's worth finding out if your company can benefit from making the transition.  It's worth taking a class and getting hands-on practice using it - reading about it can only do so much.  It's worth starting the conversations around what Agile is and how your company can benefit from Agile principles, if not from Agile practices.  You have to start somewhere; start with the conversation. Build interest.  Discuss the problems you are trying to solve.  Even if you don't adopt a flavor of Agile, having these kinds of conversations could lead to making changes that are needed to help your company be more successful.

We're going to take another detour from the Flavors of Agile and, instead, touch on a few points from the CSPO class I participated in, last week.

For those of you not aware of what CSPO means, it stands for Certified Scrum Product Owner; it's the business side of Scrum.  In a nutshell, the Product Owner is responsible for creating & prioritizing the product backlog, answering the developer's questions so that they know what to build, maintaining the product backlog, and accepting or rejecting completed work. 

I need to give a disclaimer before I continue; I consider the information taught in the CSPO class to be valuable.  I'm not going to rehash the class, step by step.  Instead, I will be addressing some areas where I feel more could be done.  I recommend this class to anyone wanting to gain a greater understanding of how Scrum works.  In fact, if you want to be a scrum master, I recommend you take both the CSM and CSPO class.  Don't let the following criticisms dissuade you.

Early in the class, the instructor introduced us (or re-introduced, in some cases) to Simon Sinek's concept of the Golden Circle, where you express why you do what you do, how you do it, and then what you actually do.  This was in relation to developing a project vision, but I think it has larger application.  I was hoping that this would be how the class was taught.  It was, to some extent, but there were some pieces that I feel were missing.

For starters, 'who' was missing.  I like the concept of the golden circle, but who you are doing things for needs to be considered before why.  The class addressed why, how, and what from the point of shortly before the first sprint planning session.  The gap was the sequence of events in the early stages of a project.  Who, why, how, and what are important, but in a training class, when is also important, even if it is just for one possible approach. 

Another gap is the notion that the scrum master is the coach for the product owner, even before the first sprint planning session.  How can a scrum master coach a product owner and be responsible for making sure the product owner holds the needed meetings and communicates effectively with stakeholders (as stated during the class) when the scrum master class does not teach everything that the product owner should do, prior to the first sprint planning session?  I can't coach someone or be responsible for making sure they do their job, if I don't know what that person is supposed to do.

Let me be clear… I am not criticizing the instructor or the training provider.  The only reason I don't praise them is that it would not be fair to associate them with my criticisms.  I am criticizing the approach to how Scrum is taught which is, in large part, controlled by the Scrum Alliance.  The CST develops the content, but Scrum Alliance has guidelines for it and has to approve it.  If you take a Scrum class, you are learning how to use Scrum in an environment that already uses Scrum.  You are not learning how to implement Scrum from scratch.  You can borrow bits and pieces, but if you don't take a top-down approach to implementing Scrum across an organization, you will be lucky if all you do is fail.  I'm not sure you can take a class on 'How to Implement Scrum' without first engaging a consultant to help make the actual transition.  I may have to look into that.

I don't fault Scrum Alliance for taking this approach.  There is no one-size-fits-all approach for organizational change, and that is what implementing Scrum is.  I think it would be easier for companies to recognize the benefits of moving to Scrum if Scrum Alliance was more involved in accurately defining the bigger picture of 1) who should use Scrum, 2) why they should use it, 3) how to make the transition to Scrum, and 4) what to do once the transition is made.

It's time to take a brief intermission from the Flavors of Agile.  If my weekend had just been a 4 hour post SAP test environment refresh validation that turned into an ALL DAY event (as if that wasn't enough), you might be hearing about LESS, and possibly SLIM.  However, life had other plans for me.

Saturday was a loss, at least with regards to writing.  I did get a short break, and took my wife out to Brazilian bbq, so it wasn't a total loss, but I don't feel like I had a weekend.  Sunday evening, we had a not completely unexpected guest for dinner, followed by a conversation that you're never ready to have, no matter how ready you are to have it.  My oldest daughter and her boyfriend wanted to have a conversation with my wife and me, after dinner.  You might be able to guess where this is going. Yes, she wants to upgrade 'The Boyfriend' to 'The Fiancé.'

When did I get old enough to have a daughter who not just wants to get married, but is legally able to?

I won't go into the details of the conversation.  I kept my inner project manager restrained, but I was envisioning risks (oh man, the risks), timelines, budgets, stakeholder analysis, and thinking who the heck is going to be the sponsor?  Maybe a committee, but we'll still need a product owner, maybe more than one.

I was good and did not use any project management jargon, but we did remind them that getting married is about more than just setting a date and showing up (although both help).  Thoughts of requirements, deliverables, and work packages started spinning around in my head, but even more importantly, ROI.  The young suitor assured us his every intention was to provide for our daughter.  We encouraged them to make sure they both agree on what that means; they need to agree on the success criteria.

I'll get back to the Flavors of Agile next week.  We'll see what happens the week after that; we're going live with HANA on CRM that weekend, and I may have other things on my mind.

A bit of advice.  If you're preparing butter chicken and want to soften your ghee in the microwave, make sure the foil from the safety/freshness seal has been completely removed from the rim of the container.  Unless you want to watch a fireworks show in your microwave.  I have to admit, it is a little bit exciting, but I don't recommend it.

Microwaves are ubiquitous enough that most people should know, by now, that you should not microwave metal.  Have you ever started a project and skipped a little step or detail, only to have it come back and bite you, later?  That's all this bit of foil was on the top of the ghee container.  A tiny detail.  It would have taken less than a moment (measure that!) to scrape it off with the back of the knife I was going to use to remove the ghee from the container, if I had bothered to check for it.  Fortunately, nothing was ruined.  The ghee did not catch fire.  The microwave did not blow up.  If you've never heard me say this before, I'll say it now; exciting can be overrated.

I bring this up because of this week's flavor of Agile - SAFe, or the Scaled Agile Framework.  Is there something about SAFe that makes it safer than other flavors of Agile, or is it just a catchy acronym?

Even though there is a set of general Agile principles, authors of the many flavors of Agile seem to feel compelled to add their own principles, or variations of the originals.  SAFe is no different.  SAFe has nine Lean and Agile principles:

1. Take an economic view
2. Apply systems thinking
3. Assume variability; preserve options
4. Build incrementally with fast, integrated learning cycles
5. Base milestones on objective evaluation of working systems
6. Visualize and limit WIP, reduce batch sizes, and manage queue lengths
7. Apply cadence, synchronize with cross-domain planning
8. Unlock the intrinsic motivation of knowledge workers
9. Decentralize decision-making

…and four core values:

1. Alignment
2. Built-in quality
3. Transparency
4. Program execution

Don't misunderstand me. These values and principles do not replace the agile manifesto and twelve general principles behind it.  They attempt to add additional meaning and structure to them, while discussing how to apply them to your business as you use SAFe.  For example, the following statement is made on the values page; I completely agree with it.

"While empowered Agile Teams are good (even great), the responsibility for strategy and alignment cannot rest with the accumulated opinions of the teams, no matter how good they are."

SAFe provides a tool for determining where decision-making should lie, for each type of decision that needs to be made.  Some decisions should be de-centralized, while others need to remain centralized.  Understanding the difference and empowering the right people to make the decisions that they should be making is part of the main principles behind SAFe.

I'm hoping that someone who uses SAFe can reply to the following statement, and let me know if I am on or off the mark.  SAFe can almost be called Lean Scrum+.  It's Lean, and it's Scrum, plus organizational considerations and practices that Scrum does not address.  It even includes guidelines for implementing SAFe, which not all flavors do.  It also discusses SAFe at the enterprise level.  I recommend reviewing these guidelines regardless of which flavor of Agile you are going to implement; much of the information applies regardless of which flavor you are implementing.

Check out this video for a five minute overview of how SAFe works.  You'll see similarities to and differences from other flavors of Agile.

So, is SAFe safe?  As you take agile practices combined with best practices for implementation and enterprise considerations that most executives are familiar with, it certainly feels safe.  It's a few years old, but I found a blog post where Ken Schwaber was not shy about his feelings for SAFe - decidedly not safe.  I know people hate this answer, but it depends.  Companies have failed implementing Scrum; can you say that Scrum is always safe?

Sometimes, implementing something that fits your organizational culture is the best way to go.  Sometimes, you need to shake things up and go counter to your culture to achieve success.  It's harder, but disruptive change is not always a bad thing.

I feel like I've just solved a riddle.  You can be SAFe and disruptive at the same time!

Unlike some of the other flavors of Agile, Feature Driven Development (FDD) is intended for larger teams, anticipating that team members will have disparate experience and maturity levels.  The latest FDD processes can be found here, if you don't mind reading ten pages of process reminiscent of the PMBOK.  Or you can keep reading, here. I can't promise it won't be dry, but it's less than ten pages.

FDD is built around five processes, the first three are done before development work begins (shh, don't say Sprint '0'), while the last two cover design and development:

1. Develop an overall model - don't let the name fool you; this is not big up front design.  The model is a living artifact that identifies tasks and quality checks, and is used to discuss, challenge, and clarify requirements.
2. Build a features list - features are small, client valued functions that typically take 1-3 days to implement.  They may take up to 5 days, but never 10 or more.  The Features List is organized into three levels, broken down by Areas, Activities, then Features.  Between you and me, this sounds a little bit like a work breakdown structure.
3. Plan by feature - Sequence the work, create an initial schedule, and assign responsibilities.
4. Design by feature - collaborative analysis and design of the features for an iteration, concluded by a design review.
5. Build by feature - Coding, unit testing, feature testing, code inspection, and build

Primary FDD Roles are:

• Project Manager - the administrative lead for the project
• Chief Architect - owns overall design of the system, responsible for collaboratively facilitating the system design
• Development Manager - manages day-to-day resource assignments and development activities. May be combined with Project Manager or Chief Architect.
• Chief Programmer - experienced developers who lead feature teams and facilitate iterations.
• Class Owner - experienced developers
• Domain Experts - people with deep business knowledge who provide input into tasks the system is required to perform.

There are also several supporting roles that may, or may not, be needed based on the size of the project.

In addition to having a Project Manager (gasp) and a hierarchical team structure, there are more practices of FDD that make it different from other flavors of Agile:

• Feature teams consist of 3 to 5 people who own the classes they are working on, so that there are no dependencies between teams.  You can expect there to be multiple feature teams on an FDD project, unless it is a small project.
• Team members (or Class Owners) may be on more than one team at a time.
• While iterations may last up to two weeks, they may only last a few days.  They are not fixed length, and the start and finish of one iteration by one Chief Programmer may not line up with the start and finish of an iteration being run by another Chief Programmer.
• The Chief Programmer chooses the work that will be included in the iteration.
• Tests may be written before or after coding is complete.
• There should be a "regular" build, but this could be weekly, daily, or continuously.

I won't argue whether or not FDD is scalable for large projects.  The literature says it was built for larger projects; who am I to argue.  I will say it comes across as development centric; however, this is not necessarily a negative point.  It is not the only flavor of Agile that is development centric, and FDD processes could be a fit for your organization. 

Transitioning to FDD may be an easier transition than Agile flavors with a flat organization structure simply because of how your organization currently works.  It's not about how the process looks on paper; it's about how it fits your organization. 

Keep in mind that if you fail to adopt one flavor of Agile, you may not get a second chance to pursue another.  There is still a large knowledge gap, when it comes to Agile and its many flavors.  If one flavor leaves a bad taste in the company's respective mouth, it may not want to try another even if it knows there are other flavors.  This brings us back to why I am reviewing flavors of Agile.  It's a learning process for me, and it hopefully gives you a resource to help you determine which flavor of Agile will be best for you.