Delivery Risk is Found in Your Teams

In my QValue Portfolio Scoring model, the way we develop the risk model is to focus on our teams. The reason we do that is that teams manifest risk in your organization and if you look at their delivery cadence sprint over sprint you can assess the risk of delivery by quantifying the team’s predictability.

Predictability often becomes a weaponized performance metric, but this is not at all what you should be doing. First, you need to understand that a team’s predictability is a manifestation of the inefficiencies of the organization in general. For example, if there is an inefficiency in the flow of work to teams due to a lack of strategic direction and roadmap, this will manifest itself in team delivery cadence as they jump from one top priority to another.

Risk in the QValue model looks specifically at the cost the risk may entail. We don’t directly look at risk from a delivery date perspective as we are focused on delivering small strategically aligned outcomes that are associated with an expected return which is then compared to the expected cost of acquiring that value. Unpredictable teams, through no fault of their own, have a higher risk of their estimates (and cost) being larger and taking longer to deliver.

Moving to an investment mindset for our technology portfolio we need to assess our expected return relative to the risk to that return from a cost perspective. At some point in time cost may exceed the return. The QValue model provides the framework to make informed decisions on whether to continue investing or move to something else.

If you want to understand where to invest in organizational/process improvements, look no further than the impediments your teams face, from lack of strategic direction, siloed management decision-making, and lack of clear objectives to high levels of technical debt or lack of automation. Your teams are the guiding light showing you where to make organizational process improvements that will support the smooth delivery of valuable technology solutions.

Why you need to have an Investment Mindset to Manage Your Product Development Intake

If your organization is like most, you have an annual planning process where your functional leaders come up with things they think are important to do and then provide a cost estimate to your PMO, ­then you are not having the right conversation in your planning process, nor are you making an informed decision as to whether these disparate projects have strategic value.

In the worst-case scenario, you have two different groups working on opposing efforts or they may both be working on the same capability, meaning you have doubled your cost for the same capability (at a minimum).

By focusing only on cost, you are missing the key aspect of your investment in your software and product capabilities that support and drive your organization. 

To ensure that you are building real long-term value you need to develop a value-based investment mindset that incorporates expected value (outcomes), cost, and risk associated with an anticipated investment.

My valuation model translates your organizational strategies into value scores that are associated with quantifiable outcomes.

When an idea is submitted, it is accompanied by a lean business case and a value score.  The value score defines the outcomes at the outset of any planning.

It allows for healthy conversation in the Intake stage as to whether or not the idea should even be considered, value score aside.

You have limited investment dollars for your software/product development and you cannot waste them on work that is not valuable or aligned to strategic outcomes. 

In truth, your software is filled with features and capabilities that are rarely or ever used.  Keeping people busy working on things that have no value is not any fun from a technology perspective and it fills your code base with significant tech debt since many of these unneeded features were part of a project plan associated with unrealistic dates. 

Moving to an investment mindset also gets you thinking about the flow of work to teams over the project and date-driven work that is already decided upfront.  Developing a consistent flow of work for your teams is one of the single most important steps you take to develop mature agility.

Additionally, by taking an investment approach you allow for investments to be stopped, just as you might drop a stock from your portfolio if it isn’t performing to your risk/return profile. 

You would do well to adopt the investment maxim that I was taught, have a sell trigger as soon as a stock price drops below a certain threshold, meaning don’t hold onto bad investments to the point they have no value.

What this means from an agility perspective, is that you have the power to stop investing in an idea if you discover that the cost or the efficacy of the idea won’t deliver the value you had expected.  In your waterfall project approach, you would be forced to continue the project even if you had realized it wasn’t going to deliver what was expected.

If you would like to learn more about my Portfolio Valuation Model connect with me at michael@soundagle.

Developing an LPM defined by Value and not Cost of Delay

The Agile Manifesto states ‘Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.’

The problem is that most organizations haven’t defined what value is and they aren’t set up to deliver it continuously.

To do both we need a way to translate our strategies and objectives so that it provides consistent and relatable outcomes for our customers.  Creating a consistent flow of valuable work via continuous intake is the way we need to work, your teams won’t be effective in another setting.

By not doing this we do what many organizations do and pursue features and capabilities that an individual customer might pay for (or someone internally thinks might be valuable), which tend not to be aligned to product strategies that move us materially forward.

The only way to enable all of this is to have a strategically aligned Portfolio Valuation Intake model that results in a consistent valuation of initiatives, features, and capabilities flowing to your teams.

SAFe’s Lean Portfolio Management approach is a good start, but there is a limitation with using the Weighted Shortest Job First method as it focuses on the cost of delay over value delivered as its method for prioritization.  My Portfolio Valuation model is designed to integrate with SAFe or any other Program Intake process you may currently have.

We want to move away from a focus on cost and change to an investment mindset that causes us to define the organization's risk and return profile for the work that delivers defined value via ROI.

Look for me at the Enterprise Agility World conference where I’ll be talking about the importance of moving to a value-based investment approach to your Product Development efforts.

In the meantime, if interested ping me via Linked In or michael@soundagile.com

Changing Your Funding Model is a Requirement for Success in Agile

When you are considering moving your organization to Agile the single most important decision and change you will make has nothing to do with the frameworks that you will select for your teams to operate under.

The change that provides the foundational support for these frameworks is about how you fund the work that these teams will do. 

Agile frameworks are not designed to support fixed budget, date, and scoped projects, yet that is exactly what happens when most organizations ‘Go Agile’. Teams start working differently but Management and Finance stay aligned to annual funding cycles and weekly project plan read-outs.

To lay a foundation for success in Agile, you need to change your funding model, moving away from funding projects in annual planning cycles to one that funds dedicated teams where work will flow to teams continuously. 

Much of the resistance in making this change comes from the fear that Finance will never change and this is just the way that they have to manage the books. The reality is far from that, organizations can and do make the shift from funding projects to funding teams, and when they do the entire dynamic of how work is managed and delivered changes dramatically.

For Finance this shift simplifies financial management because instead of having to manage the P/L for hundreds to thousands of projects, you will have a single entry for each team, which on average costs (blended rates) around $1 million annually. So if your organization has 40 Product teams you can expect the cost of delivering software to be $40 million.

By changing the funding model from projects to teams you can then shift your focus to Value, building a value-based Portfolio approach that identifies a risk/return profile for your organization and products which will allow for the appropriate investments to be made.

The shift to funding teams requires a change in decision-making that ensures that we are balancing what is identified as the most valuable against the cost because not everything we do can or want to should be done.   Moving to funded teams does not remove the fiduciary responsibility everyone has to make sound investment decisions.  

This change to delivering features in a continuous fashion allows for capitalizing on a more frequent basis which has its own benefits from a financial reporting perspective.

Agile Planning in 3 SImple Questions

Should We Do It

Can We Do It

Will We Do It

Answer these three questions before you start on any large initiative

Asking Should we do it starts a conversation around whether this is strategically aligned with our goals and objectives.

Asking Can we do it then moves the conversation to whether or not it’s technically feasible, what types of architectural enablers might we have to invest to deliver on this idea?

Once we have answered the Can we do it then we need to move onto the important aspect that will drive the final decision do it — Cost.

Just because we CAN do something doesn’t mean we SHOULD. At one organization the business came to us with an awesome idea (no really it was) but when we told them that could take more than 20 sprints to accomplish (almost a year) the business said that it would be valuable to them if it was 4–6 sprints but not more than 20. This caused them to go back to the drawing board to refine their objective goals.

Once we evaluate the strategic alignment, technical feasibility, and the potential cost of initiatives, only then are we ready to pull the trigger to invest in this idea.

Asking the Will we do it, provides everyone an ability to confirm that this is the right decision and then make that investment decision transparent to the organization.

It may sound non-Agile in approach (it’s not Discovery is an important component) but before we invest our teams in large Initiatives we should take some time to assess whether that is a good idea to do it in the first place. Just because something can be done doesn’t mean it should.

Why Aligning Value and Strategy is Important

Value is often in the eye of the beholder and because we attach ourselves to the perception of that value we can’t often differentiate between what we want and what we need.

As leaders, we often follow a similar approach when deciding what projects we should take on for the w\organization.  For instance, we may read about something interesting that another company is doing and think that we should be doing the same thing, this becomes your want.

Unfortunately what that other company is doing may not be what your organization either needs right now or worse is not even strategically aligned to its strategies.

All too often organizations have an annual planning cycle where individual leaders pitch their ideas for new projects and request funding.  And all too often these projects are disjointed, competing with other projects seeking opposite outcomes, or are even duplicate efforts leveraging different technologies, all because their focus is more on wants over needs for their capability.

So how do we move from thinking in wants to acting on needs?  It starts with transparency and alignment to the organizations' strategies.

How many people in your organization know and understand the strategies that are key to delivering value to your customers?  How many more define their initiatives around those strategies?  Unfortunately, the answer is very few. 

To start you need to create a Portfolio Valuation scoring model that is tied to your strategies and then provides a scoring mechanism that is aligned to Objectives and Key Results.  The key results form the basis of the value factors that will generate a score for each initiative.

By aligning the scoring engine to strategies and having the value factors aligned to metric outcomes, we can apply the scoring model across the organization holistically.  This is key to moving from a wants to needs conversation in the organization.

Having implemented this model in several organizations what happens at the leader level is that they have a harder time justifying investments that they want if they have low scores associated with them.  How do you convince leadership that it’s a good idea to invest a million dollars in a project with a value score of .5?  The answer is it’s not easy.

At one organization that had been trying to make the case to invest in a new ERP system with no success, we were able to tell the story better when leadership saw that they were investing large sums of money into low-value returns.   So the scoring model isn’t just to stop you from working on the wrong things, it also informs future investments to support fact-based decisions.

Value needs to be the driving focus of any organization as you have a limited amount of investment capital for software development.  Adding useless features that don’t align to strategy and have low-value returns is a waste of money

Additionally building things you don’t need adds bloat to your tech stacks as this code still has to be maintained and supported long-term.  The cost of any feature is never just related to its development cost. 

Launching SoundAgile Consulting

I've been involved with Agile with many different organizations now for over 12 years. In these years I've primarily been involved with being a contributing individual over a being an Agile coach.

The business of Agile has grown to a significant size and has now become a product that is sold to businesses who want to move their organization to Agile.  The very people who started Agile off as a movement have splintered off into several factions, each having their own opinion or approach in how to help organizations adopt Agile as a capability within their organization.  We now have Scrum, SAFe, DAD and LeSS to name a few in our acronym vocabulary.

Agile can indeed bring about valuable changes to an organizations ability to deliver software product more quickly.  These areas of Agile are fairly thought out, User Stories, Continuous Integration, Automation and Scrum.  You can move your development teams to a faster pace with some focus on specific team and development techniques that require some time to learn with some level of ease.

What Agile is struggling with is at the organizational level.  The Agile manifesto is specifically focused on building software better with a goal of delivering high value and quality software to our organizations.  A noble cause for sure and one that was sorely needed, given the changes in our software capabilities over the past 20 years.

Sr. Leadership however hasn't changed much, still managing in a large up front analysis budgeting process which creates a painful friction between fast moving product delivery teams and slow moving hierarchical management structures .

For those organizations who are being sold Agile as a product that will deliver 'x' benefits know this about what is occurring.  These organizations are finding people who have done 'some' to 'no' real Agile, meaning they haven't actually worked on an Agile team. Getting people who have the 'right' certifications doesn't provide those people with the ability to coach teams in the reality of Agile, only the theory of Agile and their current frameworks.

They are also focused only on the product development area of your business, letting you believe that you will receive huge benefits from moving to Agile without the corresponding changes necessary throughout your entire organization to support a fast paced product delivery teams.

Agile is not a small change management effort, rather it is a multi-year impact to your organization, that if done well will lead you to great success.  If done poorly will provide you with significant pain without any corresponding benefits.

I've spent many years thinking about what I might offer from an Agile consulting perspective and I've come to the conclusion that any Agile 'consulting' work that I would want to engage in must include both Sr. Leadership down and the team level.

Another thing I have concluded is that successful organizations that want to become Agile, must do so with a much smaller footprint of coaching.  You don't need full-time coaches for a long period of time.  In relying on full time coaches you are asking them to be your organizational Agile cop over owning the change within your organization.  The most successful Agile organizations I've worked in never had an Agile coach. Let me repeat that, never had an Agile a coach.  Instead they owned the move to Agile from the top down.  They provided the opportunity for teams to be empowered and fail and were not afraid to change organizational processes when they became impediments to improving Agilty.

SoundAgile will provide two levels of support and coaching for your organization.

1. Team Level - Coaching and training will be accomplished through a combination of online training videos, 1:1 coaching and targeted onsite sessions for specific techniques such as Discovery/User Story Mapping, User Story Writing and Behavior Driven Development.
2. Management Level - This will cover every management level in your organization, especially focusing in on your most impacted people, your technology managers.  Coaching and training will again be accomplished utilizing videos, 1:1 coaching and probably most importantly, targeted 1-2 day sessions that will continue for a multi-year time period. These sessions will provide for a longer term inspect and adapt change management process.

I'm really excited to be launching SoundAgile and am looking forward to working with people and organizations as they engage and encounter this thing called Agile.

SoundAgile will be live within the next two weeks.  I look forward to working with people who are motivated to move to Agile and make it work for them and their organizations.

Top Down or Bottom Up - Large Scale Agile Adoption

So I've worked in both large and small organizations where we have gone through an Agile adoption or the phrase of the day, Transformation. Having seen both sides of the coin I started realizing that you have two paths to take when considering moving your organization to an Agile delivery methodology.

I use the phrase delivery, because I think at the end of the day that is what we are talking about.  Strip away the manifesto's goals of conversation over documentation, accepting change, etc...What are are really talking about is moving an organization from a Project delivery methodology to one that is Product delivery oriented.

What is the difference?  From a Management perspective actually quite large.

1. Project Delivery - These have very strong controls which move people to a new project.  Budgets are set up for the specific time period of the project and then up front requirements and design are completed in order to ensure that the project is fully ready to be engaged.  Project Managers manage all facets of the project via extensive project planning and plans.  Management receives up dates as to the project progress on a regular schedule, usually weekly. Resources are assigned either in full or in part, yet no one actually monitors nor can they really manage whether or not someone is working 25% on a particular project.  Projects tend to focus on reporting and there is high pressure to ensure that individual projects are green, which drives teams to deliver on the easiest and often less valuable parts of the project first and only at the end of the project is the hard work tackled, which reveals itself as budget overruns or timeline delays (or worse delivery of reduced scope).  Project reporting is elaborate and management receives project reports that are often sanitized.  Value is typically not delivered to the organization until the end of the project.
2. Product Delivery - The work that is done for a Product is centered around a value stream it delivers and the work is ongoing.  Teams are funded as a whole and are kept together long-term in order to maximize their productivity.  Work is planned out in short increments called Release Plans that span anywhere from 6-12 weeks, with 2 week sprints.  Management receives regular updates (2 weeks) but can access information radiators at anytime, transparency is the key and goal with Agile Product Delivery.  Teams commit to work in 2 week sprints and their commitment is key to building trust with Management.  As time goes by management can trust that both a teams abilities and productivity can be counted on.  Teams are focused on delivering high quality code to production every two weeks which brings value to the organizations investment in them along with the increased value in terms of new sales, reduced costs, etc...Feedback loops via Product Demonstrations provides management the ability to assess where they are going with the product and deliver not what was asked for up front (Project Delivery) but rather what is actually needed (Product Delivery).

So what does the difference between Project and Product delivery approaches have to do with Agile adoption, well everything.

Most Agile adoptions begin at the bottom of the organization with the teams tasked with developing new software.  These efforts are borne, as the Agile manifesto was, out of frustration with how software was being developed in their respective organizations.  Often management is aware of the issues these teams face but are unable or unwilling to make any changes to how things are currently working and why would they?  You learn very early in your career that rocking the boat is not something that goes over well with organizations, my first boss told me I couldn't by computers that weren't from IBM because you don't get fired if you buy IBM. The message is that if anything goes wrong you need to point to well-known names, processes, etc.. with which to blame or use as support.  To think that this doesn't go on today is to place your head in the proverbial sand.

Though we can have great success with bottom up Agile adoptions with respect to improved productivity within small groups/teams, the overall Project oriented organization is typically still in place.  Management still wants to see project plans, have things 'planned' out for up to an entire year, they aren't comfortable with the fuzzy feel of product roadmaps.  They want commitments, even false ones, so that when things fail they can point to the fact that they had all of their planning in place.

For Agile to really take hold, Sr. Leaders need to change the way that they manage both their people and the work.  It starts first I think in understanding that we have not learned how to speak to management very well yet from an Agile/Scrum perspective.

We need to understand what management is really concerned about and then center our product delivery efforts around that.  One of the problems that we face with some of our leaders is that they themselves don't always know what to be focused on, they are looking at multiple balls in the air but at the end of the day as a Sr. Leader I think I have just a few things I should be focused on:

1. Growth - This is often related to sales, market and revenue.
2. Profits - Tightly aligned with the first item, our ability to make a consistent profit is what helps us continue to reinvest in our company.  Ever increasing revenue or sales without corresponding profits will eventually lead a company into bankruptcy, money isn't free and it is not endlessly available, in spite of what we think we see with new technology organizations.
3. Organizational Excellence - Because none of the above can happen unless you have a great organization.

Agile actually addresses all of the above, yet we spend more time talking about how we will improve our individual work efforts which causes us to  fail to tie this to the needs of management.  Management on the other hand often views the improvements that come from the bottom up approach as more of an anomaly rather than an organizational improvement worth adopting.

Trust is the missing component when it comes to conveying how Agile will make the entire organization better.

Agile isn't easy and it requires skills that frankly many of our Sr. Leaders lack or don't fully utilize and the politics of most organizations reward behavior that doesn't align with Agile principles such as transparency, open honest conversation and openly questioning the status quo.  We have people in power who got there by way of the non-Agile status quo and changing that means they have to learn how the new game is played in order to stay on top, it's much easier to keep things they way they are over learning how to navigate the new.

So how do we speak to our Sr. Leaders with respect to Agile?

1. Better ROI - Talk to any Finance executive about what they look at when purchasing a piece of equipment that will deliver revenue and you will hear them talk about Net Present Value of the investment, Positive Cash Flow and Depreciation costs.
   1. We improve ROI in Agile due to our focus on only the most valuable items.  In non-Agile project work often are working on features/functionality that may be important to someone inside the organization yet will bring little or no value to the organization.
   2. When we are able to start talking about the value streams of our organization, be they revenue, cost reduction or improving our brand image we begin to be able to have a better ROI conversation with management.
   3. We also positively impact ROI via higher levels of productivity gained with dedicated teams.
2. Flexibility - One of the most important elements that 21st century organizations require is the ability to be flexible enough to react to market forces or reactions.  Financing large projects far out into the future with the expectation of some level of return and no we don't really have great track records of predicting future ROI out very far into the future.  With Agile we provide the framework to identify the most valuable work for the business in small planning windows.
   1. Sr. Management needs to understand that this flexibility comes with an obligation to have consistent short term review windows as the team progresses so that we deliver what is actually needed and not what we thought we wanted.  You may have thought you needed a Ferrari when in fact what you needed was a mini-van, we provide the framework to course correct via Sprint reviews every two weeks.  If you plan all of your project up front for the Ferrari, we'll certainly try to make that happen, but in reality as the end of the project nears you will probably get the car but with a lawnmower engine and no brakes, it may look like a Ferrari but it won't operate like one nor will it provide the value the organization really needed.
3. Predictability - Another key element that we deliver with Agile is predictability and accountability.  Your teams will be much more accurate in planning and delivering in short-term 2 week sprints with a planning horizon of 6-8 weeks.  What management needs to look for is consistent delivery of the committed work that the team makes, commitment is everything.  What Wall Street analysts look for is a business that can provide a solid ROI, react responsibly to their competitors or even better be a market leaders and provide predictable results year in and year out.

So the question at hand is what is better a Top Down or Bottom Up adoption?  My money for long-term success is on the organization that can consume what Agile really means, not just to their development teams but the organization as a whole.  You can't BE Agile if you don't make the paradigm shift from command and control to one of collaborative and collective delivery.

BDD Adoption - Taking time to get it right

Recently I've had the opportunity to speak with a broad range of Agile coaches and consultants who have consistently told me that they have not seen any organization successfully adopt BDD as part of their standard process of elaborating their User Stories. Luckily I have had the opportunity to work with several organizations that were able to successful adopt BDD and believe strongly in how this process can transform how you build and bake quality into your products.

I think most people hear the word BDD and they immediately think that it is an automation centric effort, though that is a great value add for BDD, leveraging BDD without automation can also lead to improved testing and quality.

Adopting BDD is so much more than automation (which I wrote about here) it's really about clearly defining the expected behavior of your system.

Why is this so important? Because as humans we all interact differently with the systems that we encounter.  As people who develop these systems we deliver based upon our experiences and understanding of the system we are building.

Language (Business Requirements) has been the manner and method that we have used to convey what we want a system to do to.  However with an international work force we don't all have a shared language.  In addition to this constraint we also interpret what we read differently based upon our primary language, life experiences and culture.  Given this, it's not surprising that when we build a system, it has many different interpretations attached to it, which negatively impacts both the functionality AND quality of our system.

BDD is a way to talk about how your system should behave not what it should do.  Yes we want our systems to have specific functions and features, but talking about how each of these will behave brings about a much richer conversation of what can happen in many functional situations the system and the people will encounter, not just the happy path.

There are two primary components of BDD:

1. The Given/When/Then test setup
2. The Example Table

Getting the first part of your BDD is the most important component because it defines the size and scope of what the User Story.  We do that by decomposing an individual user story into Test Scenarios.  One quick way to determine if your user story is perhaps to large or complicated is to evaluate the number of Test Scenarios you can define.  Keep your Test Scenarios to under 4 per each individual User Story so that you can more easily understand the expected behavior for that part of your feature or functionality.

Keeping the number of test scenarios small is also important once you translate your BDD into test automation which will keep your tests small so when something breaks it is much easier to find out where you need to address a fix.  Remember development teams should be consistently refactoring their code to improve code quality.  With high levels of automation we can quickly catch when refactoring unexpectedly changes the underlying behavior of our system.  This is where Quality is kept front and center in our organization.

The second part of building effective BDD is the Example table.  My training focuses on getting the first part clear and clean because the example table is an easier effort of filling in the expected results in each of your parameter columns.  As with the first section you can use the number of parameter columns as a means of determining if your test scenario is too large.  Try to keep the number of parameters to between 4-8, anymore will result in more brittle tests and more time debugging your automation code.

Adopting BDD as your primary means of decomposing stories may on the surface seem like a lot of work, but remember that you are only doing this level of detail for each 2 week sprint so the number of stories that you build out context driven BDD is relatively small.  Doing it every sprint means you get better at it every time and you will refine your ability to generate BDD much more quickly.

We should also remember that this is a TEAM oriented approach, don't relegate this to your QA team, you will miss getting all of the context needed to delivery high quality code and functionality.

GSD or Feeling Good about the Wrong Things

Over the past couple of years I have heard the term GSD used quite a bit as a means to describe high-performing individuals (note I did not say team). I have to admit that this is not an acronym that I was very familiar with, primarily GSD referred to my designation in college as someone who didn't want to join a fraternity, the politically correct term would be Gosh Darn Independent (And this is probably a great way to define who I have been throughout my career).

Before embarking on this post I did some quick google searches and came up with some thoughts on GSD:

1. The Urban Dictionary definition:
   1. GSD is brought about through severe bout of procrastination, not getting work done on a regular basis, therefore needing to set aside long amounts of time to disappear and get shit done.
2. What Spinks Thinks - http://whatspinksthinks.com/2013/11/04/get-shit-done-the-worst-startup-culture-ever/

The term, as it is used now is, Get Shit Done, which does sound great at first pass.  However when you start working with GSD as part of building a defined delivery process you start to see some very ugly things drop out of it:

• Heros - Those great people who came in and saved the day and got some serious shit done under intense pressure.  Never mind that the day they were saving maybe shouldn't have happened in the first place or even worse, the situation requiring them to save the day via GSD was of their own making, convienently lost in the thrill of GSD.
• Lack of Defined work - Who cares what I am doing so long as at the end of the day I can show you how much shit I got done.
• Lack of Plans - See above.

The problem as I see it with GSD is that we aren't asking ourselves a basic question - Are we doing the right shit at the right time?

Yes getting 'shit' done is good and getting it in done makes us feel good, however if there is no real process behind your way of getting shit done then you will be destined for unpredictable delivery of the work that brings your organization the most value.

I find in my experience that GSD is more about individual glory over a team (see my blog on Teams Deliver) which I find troubling on so many levels.

Organizations spend lot's of money having their technology teams deliver features that they believe bring value to the business and even though there may be many ways of delivering this value, ie Agile, Waterfall, Lean, I have yet to see GSD making its way into main stream product and project management lexicon.

Continuing my educational tour of the world of GSD I found a posting from two guys named Daniel Epstein and Pascal Finnette who appear to be individuals who provide support, coaching and services to technology entrepreneurs specifically regarding GSD:

1. GYSHIDO - A movement started a few years ago dedicated to The Art of Getting Your Shit Done.  They identified that their most intrinsic value as employees was that they got shit done, but in looking at their code of honor I see elements of good process, so is it possible thatGSD has some value?  Too soon to tell.  But here is their code of honor:
   1. Relentless focus - Focus on the 10% of your activities which drive most of the value. Relentlessly.
   2. Boring consistency - Do the right things over and over again. Consistency forms habits. Habits make hard things effortless.
   3. No Bullshit - Don't bullshit yourself or others. Apply brutal honesty and transparency to everything you do.
   4. No Meetings - Meetings come in only two forms: Standing or social. If it's social, it's over breakfast, lunch, coffee, dinner or drinks. If not - don't sit down.
   5. Follow up - Don't let others wait for your part of the job. Ever.
   6. Don't be an Asshole

As I read through their ethics I believe (I haven't talked with these guys) that their process could align with the agile type world.  Why?

• Many of the elements of what they believe is good GDS is what I consider good behavior of Agile teams:
  • Focus on the work that delivers the most value - Agile, 2 week sprints, deliver production ready features continually.
  • Consistency - Keep your Scrum Teams together, let them improve in estimation, execution, test automation, boring?  maybe, get shit done fast?  yes
  • No Bullshit - Retrospectives ask us to be brutally honest when things are working and fix what doesn't work.  Attack the problem not the person (see number 6 - Don't be an Asshole)
  • Follow-up - In Agile I always talk about how we need to think of minutes over hours when resolving issues that are blocking us from completing our work.

Agile teams focus on identifying the valuable 'thing' that we need to deliver and then develop lightweight plans to deliver it incrementally. I suspect that GSD has its roots in waterfall SDLC where a project would roll happily along, green week after week, oblivious or ignorant to how the project was actually unfolding.  Decisions made by the team that never surfaced had large impacts on scope and viability of the project.

GSD I believe emanates from the need for a project team to 'pull a rabbit' out of the hat in order to deliver the project 'on-time'.  My years as a waterfall PM saw this time and time again.  We fool ourselves into thinking that we can predict a large project from beginning to end all up front, you can't, period.

So when you are rewarded in a GSD organization they are ultimately is saying that the organization values chaos over effective planning and delivery.

Agile Planning - I have a need a need for speed

Working at Disney a number of years ago was in so many ways transformative for me (not sure why I left) because it provided me with an opportunity to work with an organization that needed to get better at delivering software for our partners and we ended up choosing Agile as our path. Disney was the place where I had the opportunity to help build an Agile process from Requirements to Delivery and what we discovered was that we needed to develop an effective planning process that allowed us to build a solid backlog of work before we just started coding.  I here that so often in organizations that are just starting to adopt Agile.  I think a statement I heard recently is descriptive of organizations that just start coding - Shoot and Point.

Disney is a largely creative driven organization (Not surprising) and because of this we typically had a disconnect between our creative (UX) groups and the Product Delivery teams.  The UX team primarily worked independently of the PD teams and as was the case when I arrived, UX would deliver a creative design that didn't align to our technical capabilities.  This is a common issue in today's web development environment.

Our first 'Release' Planing went very poorly and after a round of retrospectives we came up with a format that at first pass you would say wasn't Agile (trust me we used that phrase a lot in the early days of our becoming Agile).  But in the end this first step of Discovery ended up being what I believe is the most critical element of being able to go fast in Agile.

The basic process that we ended up with was as follows:

• Pre-Discovery - Sr level PD, PO, UX, Marketing and other Stakeholders would review a specific new feature that was being considered. The group would utilize several tools such as Mind Mapping to understand the scope, parameters and potential dependencies at a high level.  If the feature work was approved then we went to the next phase.
• Discovery - Depending uponthe the size of the potential project Scrum teams and extended stakeholders would meet to go through a low-level review for that feature development.  For many of our larger efforts it was not uncommon for us to sequester the teams into a room to work through the entire effort, UX to QA to Delivery.
  • Process
    • Kick off - Have your PM or PO along with the key stakeholder(s) of the effort describe WHY this feature is so important.  We learned in our process development that it helped our PD teams to have an understanding as to why this feature was important to the organization.  It helped them feel connected to the value that was being delivered and not simply code jockeys running a race.
    • Competitive Review - Another great exercise was to have the entire team go out and find competitive features that we either did or didn't like and describe why.  This helped the next phase of our Discovery process as we worked to define what our feature sets would ultimately look like
    • UX and Story Development - This was the primary scope of our Agile workshops.  Typically led by the UX lead for the project we would begin developing low-fi wireframes and discuss the issues, constraints and code complexity that the low-fi would entail.  We discovered in this process that we could work through the types of issues that come much later in a typical product delivery effort.
      • Outcomes -
        • UX ended up with designs that they could utilize to develop prototypes that would be used in User testing prior to any significant development work being completed.  This allowed changes to UX to be found at the very beginning of the PD process rather than at the end when refactoring consumes a much larger amount of time and leads to lower quality of code.
        • PD ended up with a solid design at the beginning of the PD process which led to high quality code and higher levels test automation.
        • QA ended upon with an ability to write higher quality acceptance criteria which lead to high quality in the delivery and higher levels of test automation (sensing a theme here?)
        • User Story development was done during the Discovery phase and with it I was able to have a fairly accurate model to predict the number of stories at the beginning of the Discovery phase (typically between 100-120 higher level Epics, we strove for stories to be between 21-34 points in this phase as PD would start fairly quickly after the discovery phase 2-3 weeks) and how many that would translate into for a full project (typically 350 - 400).  This provided me with input as to how many BDD acceptance criteria would come out of this as we used a marker to determine when a story should be broken down - More than 7 variables in the BDD would be an indication that it's time to think about breaking down the story and more than 14 tests in a single test scenario would also trigger the conversation of whether to add a scenario to a story or create a new story.
          • Benefit - Keeping your BDD test automation in small increments makes it much easier to understand what broke, who probably broke it and what is needed to fix it.

I know this doesn't 'Sound' Agile (like the name of my company), but in my experience doing this small amount of work up front does provide teams the base to go really fast once the PD process begins.

I have used this process now for many years and when we do it right it's like writing a symphony, all of the moving pieces make beautiful music.  When it isn't done right, then all you get is noise.

This process probably does work for larger and more complex organizations over small organizations, but really would you start building a house with no blueprints and no idea of what you wanted?  If you had builders just show up and you told them I need a house to live in and I need it fast you will get that, but I doubt it will be anything that you want. And in reality it wouldn't be done fast as they probably wouldn't have the right materials scheduled to arrive at the right time.  I have my roofing supplies but the foundation company can't some for a month, see what I am getting at?

Slow down a bit, understand what you want, how to get it and then go fast to get it.