Addendum: Agile 2014 Proposals

I blogged recently about a proposal I submitted to Agile2014. As the deadline for submission is today, I won't be asking for your feedback on the submission website (unless you're a reviewer for the track). However, I'd still love to hear your thoughts here on the blog!

Additionally, I have assisted a co-worker with putting together 3 additional proposals as co-presenter. I'd like to share the information on all of these proposals here with you now. I cannot over-emphasize how much I want to hear what you think about them!

Practical Application of Dude's Law: Come Play the Value Estimation Game!

Abstract:

You know how you determine the "bigness" of your work and establishing commitments, but how do your customers ensure you're committing to the right thing?

Come experience relative estimation to determine value. We'll use David Hussman's "Dude's Law" (Value = Why? / How?) to prioritize the work.

We will share techniques for determining the "Why?" so that you can generate a Value Index. What many people will be surprised to learn is that they already have tools for sizing that can be used for determining value and prioritization.

Information for Review Team:

The break-out of the 75 minutes would include:

3 minutes: Introduction to Dude's Law and the Value-Driven Heuristic
10 minutes: Explain and model the first exercise (Team Estimation Game for relative sizing)
10 minutes: Have round-table teams execute first exercise with a set of 10 features
5 minutes: Explain and model the second exercise (Team Estimation Game for relative benefit - same mechanism, so it takes less time to explain and model)
10 minutes: Have the round-table teams execute second exercise with the same set of 10 features
10 minutes: Have each team determine the Value Index of each card by applying Dude's Law
15 minutes: Have teams share their outcomes, insights
12 minutes: Explain the flexibility of Dude's Law (you can use Planning Poker or whatever technique works best for you) and introduce them to concepts such as Weighted Shortest Job First and Value Dial weighting*

* As this section is the least important it may be reduced or eliminated if previous sections run long

Prerequisite Knowledge:

The concept of Relative Sizing (Story Points, T-shirt sizing, etc.)

Learning Outcomes:

1.       Experience and learn how to apply a practical, proven game for prioritizing your work based on value

2.       Understand that using a heuristic for valuation is better than both gut-feel and over-engineering

3.       Understand that, as with estimating size/cost, the real value comes from the conversation

Presentation History:

I've done the Team Estimation Game dozens of times before with as many teams and have done the exercise including benefit to determine a Value Index with at least one of those teams. I also have led Program Management teams through a very similar prioritization matrix model that leverages the concept of Weighted Shortest Job First.

Comment:

My presentation is a reflection of my own beliefs and experiences. None of the material I present should be interpreted as an endorsement by my employer. I have received express written permission from David Hussman to reference Dude's Law, and I am a Certified SAFe Program Consultant (SPC), which qualifies me to speak on their Weighted Shortest Job First (WSJF) Framework.

The Secret Sauce of Agile

Abstract:

Humans are basically moist robots. As much as we like to think that we are logical, rational beings, we really aren't. The best thing we can do to improve our decision-making is to influence our environment and develop skills that will increase the odds of making the right decisions.

Beyond the techniques, practices, principles, and even beyond the manifesto; that's the secret to Agile success. Through dialog, games, and an open agenda, we'll explore that secret. Together we'll find the next evolution of Agile via application of that secret.

The foundations of Agile are human centered and scientifically backed. To get the most out of Agile and to leapfrog beyond it, we need to understand how Agile works. It's the wiring of our social minds, the relationships, tacit knowledge, and our predictably irrational natures that ensure Agile success and doom all other approaches. So, what is that secret sauce that mix of ingredients?

Information for Review Team:

Introduction (7 minutes)

We will discuss the hypothesis that influencing those factors that determine our decisions is a more effective use of time than simply exerting willpower to make correct decisions. We will introduce factors of significance that we have already found and invite the audience to provide others.

Mind Mapping (50 minutes; up to 10 minutes per factor)

We will use mind-mapping to explore what we can do, as practitioners and coaches, to increase our odds of success by influencing:

1.       Knowledge and skill-set (what knowledge, if internalized and applied, will help us make the right choices?)

2.       Environment (How can we modify our physical environment to make us more successful?)

3.       Chemical makeup of our bodies (What foods, drinks, and activities make us more likely to succeed?)

4.       Removal of guesswork (What decisions can we make when in a "rational" state that will lessen the impact of impulse decisions when we're "irrational", i.e. conflict protocols, etc.?)

5.       Others as identified by the audience

So What? (Remaining Time)

Use the information to help those in the audience generate actions based on their new knowledge to help their teams and organizations succeed. This is not a theoretical exercise; this is an Inspect & Adapt exercise rooted in human psychology.

We are prepared to adjust the presentation style depending on the seating arrangement; we can make both work well.

Prerequisite Knowledge:

Deep experience with breathing

Learning Outcomes:

1.       Learn the success secrets of Agile embedded in human behavior, social science, and the way we're wired.

2.       Learn to use science and human nature to go beyond Agile.

3.       Walk out being able to use your knowledge to be more successful with Agile.

4.       Move to the next evolution of Agile.

Presentation History:

This is a new approach that we're experimenting with currently with small teams and leadership groups. The agenda is loose because every group is different and responds differently; our goal is to let those present take ownership of the meeting and take it where they need it to go.

Flexible IT Using Enterprise Kanban

Abstract:

We will walk through multiple examples of how to setup visual signaling systems to replace the wasteful reports, meetings, management, tools currently used to track, prioritize, manage, and control portfolios, investments, programs, and projects. This talk will describe the essentials of how IT can adapt to massive disruptions. The story comes from one of the world’s largest companies. We've altered things to form a generic story; but the techniques are proven, simple, working and effective. These disruptions are constant major shifts in technology and business that have been canceling and starting new programs / projects for years.

Big data, competitive innovation, mobility, leverage, and fluxes in profit and loss have had huge impact over IT. Consider having to building a data center, starting a big data pillar with hundreds of specialists, and dropping large portions of budget all at the same time. These disruptions cannot be planned for their adaptations in response to technology, financials, and business changes.

To protect the innocent, this story details in this discussion have been formed in the form of a story. However, this leverages stories from a successful implementation of enterprise kanban at a major retailer. The approach is so simple it may not seem realistic. But stories of dealing flexibly with disruption are becoming common. Our stories will be richer and will have more real without any complexity. This story leverages a chain of values, decentralized and centralized decision-making, transparency, collaborations, evolutionary architecture, and innovations. These form the backbone for allowing a simple kanban system manage the flow of a flexible approach to dealing with global, enterprise disruption.

Information for Review Team:

Ideally, this would use large post-its and sticky notes with strings in a live demonstration. Our current system uses LeanKit; but we'd like to present tool agnostic.

The break-out of the 75 minutes would include:

5 minutes: Introductions - A story of 5 Continuous Crucial Conversations
5 minutes: Pre-requisites to Flexibility
5 minutes: Disruption – Innovation – Zero Click Shopping
5 minutes: A Flexible Response –Enterprise kanban in Action
5 minutes: Business Leadership - Reprioritize IT funding (Business Investments)
5 minutes: IT Leadership – Adjust IT capacity and create big requirements– (epics)
5 minutes: Domain Leadership - Breaks big requirements into pieces, rank, and distribute work (sub-epics)
5 minutes: Team of Teams Leadership - Form domain teams, Break sub-epics, and rank (features)
5 minutes: Teams - Break features into stories, Deliver solution parts (stories)
5 minutes: Enterprise kanban as an Innovation engine
5 minutes: Enterprise kanban supported by Lean IT & Kanban Services
5 minutes: Enterprise kanban as an Execution engine
15 minutes: Q&A

Prerequisite Knowledge:

Have to have worked in mindless, massive, and. Mismanaged companies. Need to have intimate, firsthand knowledge of corporate waste, stupid status and other mindless bureaucracy. Must have years of experience trying to do the right thing while working with overly complex, boring and unproductive program and portfolio management policies, processes, methods, tools and people.

Learning Outcomes:

1.       Walk out being able to setup a simple, flexible way to connect the effort of teams of teams.

2.       Trace funding, strategy and progress to value delivery.

3.       Increase visibility and communication while decreasing reporting, meetings, and planning.

4.       Know how to use enterprise Kanban to replace status reports, time sheets, and management.

5.       Having talking points and examples that will help you set your organization free of vanity metrics, over processing, and micro management.

Presentation History:

Not formally presented outside the company internal Agile User Group

Leading Agile Transformation from a Beach: 2 Agile Coaches’ Journeys

Abstract:

Todd and Mike have both experienced the growing pains that come from becoming Agile and helping others with the same. They had similar experiences and learned similar lessons, but their journeys have been surprisingly different. One took 15 years, the other took 5, and both took longer than they had to.

This is a story of what not to do, what to do, and how do it by not doing anything. It pulls from at least six multi-year Agile transformations in some of the world’s largest companies. We'll share our experience in a story that is sometimes funny, mostly true, and utterly real. We'll save you from failures, help you see new ways of transforming yourself, teams, companies, and cultures. Or, perhaps, we'll just provide a self-affirmation opportunity for you to confirm that what you are doing is much more intelligent than what other Agilists have done.

Information for Review Team:

May have to protect names to save the innocent and spend less on legal fees. Combined transformation experience of almost 2 decades covering thousands in major companies and consulting firms.

Prerequisite Knowledge:

Must have lead an Agile transformation of a team, set of teams, company or, that hardest of all Agile transformations - yourself.

Learning Outcomes:

1.       Build confidence

2.       Teach you how to transform without working

3.       Help you avoid stupid transformations

Presentation History:

First time for this one. Parts shared at PMI chapter and local Agile User groups.

Attachments:

Leading_From_Beach.pdf

Taming the Wild West: the Differences between Agile and Cowboy Coding

One of the strongest arguments for Agile is that it’s not Waterfall. However, not everything that isn't Waterfall is Agile, a fact that’s not always understood. This misunderstanding hurts the Agile brand when people familiar with only Waterfall begin associating all other methodologies, including a lack thereof, as Agile. I want to be very clear about this: Agile is not Cowboy Coding, and Cowboy Coding is not unique to Agile teams. It is important both to understand how Agile and Cowboy Coding are different and what Cowboy Coding looks like so that you can identify it on your teams (yes, even Waterfall teams).

The Loner

One of the easiest signs of a Cowboy Coder is that he’s a loner. He may be working under the name of Agile, but there are no Agile methodologies or frameworks I’m aware of that support such behavior. In fact, the backing principles of the Agile Manifesto state, “Business people and developers must work together daily throughout the project”; “Build projects around motivated individuals”; “The most efficient and effective method of conveying information to and within a development team is face-to-face conversation”; “The best architectures, requirements, and designs emerge from self-organizing teams”; and “At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.” The manifesto, its principles, and all Agile methodologies and frameworks I know of are very human-centered with an emphasis on collaboration.

If you have a loner on your team that insists on working in a silo, there’s a possibility that you have a cowboy in your midst. Try to rein them in using mandatory meeting/ceremonies that promote meaningful conversations and practices like Pair Programming. If they absolutely refuse then you will likely end up spending considerable time managing the work around them – holding ad hoc conversations, formal code reviews, knowledge transfer workshops, etc. – with diminishing returns.

Straight to Production

Working directly with Production code or with a source code repository that isn't versioned is a bad idea. Don’t get me wrong, I love Continuous Delivery and working off the trunk, but a software development team must be very mature and disciplined to make this work. They use feature toggles and branching by abstraction to protect code that isn’t ready for Production. They build test suites around the code so that each commit is verified against regression. They do their due diligence to make sure that a change isn't going to blow up if it’s pushed to Production. Cowboys, simply put, don’t.

If you find yourself consistently in a situation where the same person or people are making changes directly to Production without due diligence then you might just be working with Cowboys. Have them read up on DevOps and Continuous Delivery so they can learn the right way to get changes to Production quickly. Emergency situations that require quick, non-vetted changes to Production should be avoided at all costs.

Wastes of Time

The Cowboy will often refer to Testing and Documentation as a waste of time. They may even commit the cardinal sin of Agile, reciting the Manifesto blasphemously: “‘Working software is the primary measure of progress’; anything else is just a waste of time!” To those people, I would ask them to define “working”. Does it pass the Acceptance Criteria associated to the work (or did you even bother to ensure you had Acceptance Criteria)? Can anybody actually use it, or is it too buggy or complex? Is anyone other than yourself aware of the assumptions made around input, output, workflow, etc.?

Without proper testing and documentation, you can’t prove your software works nor can anybody understand how it works. With that being said, if your tests and documentation don’t contribute to the value and usability of the software then they are, in fact, a waste of time. Focus your testing efforts on tests that actually stand a chance of failing and finding vulnerabilities. Don’t spin your wheels creating “write-only” documentation. This is the approach that Agile espouses; anyone who says tests and documentation are altogether useless is operating with a Cowboy mindset, not an Agile one.

“Emergent Architecture”

One of the backing principles to the Agile Manifesto states “The best architectures, requirements, and designs emerge from self-organizing teams”. There are those who believe this means “just make it up as you go.” That’s not entirely accurate. There still needs to be intelligent design, and that design needs to make the software as easy to comprehend and maintain as possible. As another principle clarifies, “Continuous attention to technical excellence and good design enhances agility.” This means having a thorough understanding of the latest design patterns and practices. It means taking the time to refactor working code into something better. It means taking a little bit of time up-front to design what you think will work and adjusting as you go.

Agile developers do not shoot from the hip. They take pride in their applications; they have a sense of ownership. They will throw research spikes, read books, build proofs-of-concept, attend conferences – do what it takes to build the right thing in the right way. You’ll spot a Cowboy by their purposeful lack of direction, sticking code wherever they please with the sole purpose of “getting something to work” so they can move on to the next thing. If they do it in the name of “emergent architecture” then call shenanigans. That’s not architecture, it’s just reckless.

Somewhere to Hang their Hat

The good news is that cowboys can be tamed if they can come to appreciate the practices, tools, and frameworks that Agile provides. Cowboys won’t jump on the bandwagon just for the heck of it. There will always be some that refuse to be tamed, but many will see the benefits and forsake their wandering ways once you give them a safe place to hang their hat.

One of the great things about reformed Cowboys is they are used to developing quickly and cross-functionally. If you arm them with XP practices, Agile tools, a Kaizen mindset, and continued training and development, they can become model developers that contribute quality software time after time.

Just don’t make the mistake of trying to get them to do something for which there is no tangible benefit. They don’t take too kindly to that.

People != Resources

Within my area, I've become famous for correcting people when they say "Resources" and mean "People". I work hard to get people to think of each other as human with a unique skill-set and personality, not interchangeable cogs in a machine. When people start complaining about a "lack of resources" I ask them to make a shopping list and I'll pick some up from the store.

Apparently, my message is getting through.

The other day I was in one of the rooms our teams work in and saw this on the whiteboard.

I thought, "Wow, I really got through to someone!" Then, I saw this underneath that:

So not only do they understand that people are not resources, they point out an example of what would be considered a resource. Then, to drive the point home, I found this:

It's true, they're not! What I love most about this is that I didn't write any of this - members of my team saw the opportunity to share a message that they had bought into because they saw the value in treating each other as people, not just resources!

Finally, a bit of nerdy humor to finish this off. What else would you expect of a bunch of geeks? :)