Taking the Plunge

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.

I was going to review AUP - the Agile Unified Process (having read about it, once, several years ago, when part of the company I was working for used RUP), but, in 2006, Scott Ambler abandoned it in favor of Disciplined Agile Delivery (DAD), which has since evolved into the Disciplined Agile Framework.  The reason for this shift was to address how to be effective at IT, not just at delivering IT solutions.

Disciplined Agile has its own manifesto and principles.  It is intended to be an extension of the Agile Manifesto, so it will seem very familiar when reading it.

Scott provides several reasons why you should choose Disciplined Agile.

1. Disciplined Agile picks up with Scrum leaves off, dealing with architecture, design, testing, programming, documentation, etc…
2. It is pragmatic, allowing you to choose how to execute it in response to your situation
3. It supports both lean and agile lifecycles
4. It is based on proven strategies used across multiple industries
5. It provides a foundation for scalability
6. It enables and goes beyond SAFe (Scaled Agile Framework; watch for it next week)
7. It is constantly evolving as new agile and lean strategies emerge

Roles are split into primary and secondary roles.  Primary roles exist regardless of the scale of the project.  They are:

• Stakeholder
• Product Owner
• Architecture Owner
• Team Lead (analogous to a Scrum Manager and Agile Coach)
• Team Member

As a project grows in scale, the following roles may be added:

• Specialist
• Independent Tester
• Domain Expert
• Technical Expert
• Integrator

As you learn more about Disciplined Agile, you'll begin to recognize flavors of other project management approaches.  It is intentionally a hybrid approach, with the intent of borrowing the best from other approaches and combining them in attempt to leverage their strengths and overcome their weaknesses.

In keeping with its emphasis on the agile organization, not just agile delivery, Disciplined Agile provides guidance on establishing and running agile Communities of Practice and Centers of Excellence, governing agile teams, and maintaining awareness of agile at five different levels within an organization.  This, combined with other practices, is referred to as Strategic Agility at Scale.  Organizational processes are broken down into lifecycles and blades.  These are:

Disciplined Agile Delivery

• Continuous Delivery
• Exploratory/Lean Startup
• Lean/Advanced
• Agile/Basic
• Program Management

Disciplined DevOps

• Non-Agile/Lean Lifecycles
• Release Management
• Operations
• Support
• Data Management

Disciplined Agile IT

• People Management
• Product Management
• Portfolio Management
• Enterprise Architecture
• Reuse Engineering
• IT Governance
• Continuous Improvement

While this is not the same process as ASAP, it's starting to feel the same - highly structured, which almost feels contrary to Agile - but that is not a bad thing when dealing with Agile at the enterprise level.

While I can't say whether or not Disciplined Agile is the best approach, I completely agree with the mindset that transitioning to Agile cannot be just an IT change.  Not only does Agile change how products are delivered, it changes how progress is reported, how requirements are prepared, how projects are planned, and more.  If your leadership is still expecting things to run the way they used to, you may struggle to get support because leadership expectations are not aligned with Agile practices - this is a concern with all Agile flavors, not just with Disciplined Agile.

Change of plans, and I apologize for the delay.  My intent was to cover, very briefly, three more flavors of Agile in one post, so that I could get to scalable approaches sooner.  These flavors are:

1. Agile ASAP
2. Feature Driven Development (FDD)
3. Disciplined Agile Delivery (DAD)

As I was working on this, I realized that I could not address all three in adequate detail without writing a short book (I'm trying to keep my posts more concise.  Trying…), and both FDD and DAD have elements of scalability built into them.  Addressing them individually makes more sense.

In case you've never worked on an SAP project (or maybe even if you have), ASAP stands for Accelerated SAP.  It is SAP's implementation methodology for SAP solutions, with end-to-end coverage of the Process Lifecycle, Application Lifecycle, Project Lifecycle, and Value Lifecycle.

ASAP addresses:

• Project Management
• Organizational Change Management
• Data Management
• Business Process Management
• Technical Solution Management
•  Integration Solution Management

…and provides templates, tools, questionnaires, checklists, and guidebooks to assist the project team.  I'd explain more, but I'm not sure I can condense a four day training class into a blog post; it is not a lightweight methodology.  So, how is this Agile?  It's not.  ASAP is the foundation for Agile ASAP.

What is Agile ASAP, then?  Essentially, it is a slightly lighter-weight methodology that uses elements of Lean and Scrum during development.  Kind of.  There's a little more to it than that, but I'm trying to keep it simple and I don't want to lose your attention rehashing Lean and Scrum. 

If you're using ASAP, Agile ASAP may be a good fit for you (transitioning to Agile is challenging), but it's really for SAP implementation projects, so I don't recommend it if you're working on other types of projects.

I've been working on several SAP implementations, over the last couple of years.  We haven't used ASAP, largely because of the technical requirements.  There are some specific requirements for your SAP landscape and SAP Solution Manager to use the methodology effectively that the company I work for has only recently started to pursue.  The new version of Solution Manager can, reportedly, be used for more than just SAP projects, and has integrated with Microsoft Project, to some extent, for the last couple of versions, at least.  It can add a lot of value if you have the time and resources to get everything set up correctly.

If you have experience using ASAP or Agile ASAP, please share your experience in the comments.