At the Agile India 2010 conference, Sandeep and I ran a workshop to shed some light on the kind of aping that’s taking place in the software companies trying to be Agile.
Clearly we don’t have all the answers. Nor do we know the best way to build software in the right way (if there was one.) But we do know one thing:
The right way doesn’t involve mindlessly following practices just because some “expert” says you need to.
In this workshop we took a critical look at various “agile” practices and tried to highlight the dogma and ceremony that has creeped in. We also questioned if the practices defined a decade ago are still applicable? If yes, have they evolved since? What are some of the original creators of these processes practicing today?
Agile gave us a wonderful head-start in a different direction than the one we’ve used to (heavy weight methods.) Personally I feel we’ve got as much value we could. Now its time to start thinking from a different direction, building on what we already know and to some extent unlearning some things we know.
Wait a second, isn’t Agile all about “Inspect and Adapt”?
There is a limit to “inspect and adapt”. If you look at the Lean movement, most people talk about Kaizen (small gradual change, change for the good, which is in-line with inspect-and-adapt). But very few people talk about Kaikaku (disruptive change or transformation).
Remember Agile was Kaikaku for most of us in late 90s. And then we’ve applied Kaizen to it for many years. IMHO now its time to apply Kaikaku again.
How good are you at limiting red time? .i.e. apply limiting WIP (Work-In-Progress) concept to Programming and Product Development.
What is Red Time?
During Test Driven Development and Refactoring, time taken to fix compilation errors and/or failing tests.
While Programming, time taken to get the logic right for a sub-set of the problem.
While Deploying, downtime experienced by users
While Integrating, time spent fixing broken builds
While Planning and Designing, time spent before the user can use the first mini-version of the product
And so on…
Basically time spent outside the safe, manageable state.
Let it be planning, programming or deploying, a growing group of practitioners have learned how to effectively reduce red time.
For example, there are many:
Refactoring Strategies which can help you reduce your red time by keeping you in a state where you can take really safe steps to ensure the tests are always running.
Zero-Downtime Deployment which helps you deploy new versions of the product without your customers experiencing any downtime.
Continuous Deployment which helps you get a change made to code straight to your customers as efficiently as possible
Lean Start-up techniques which helps validate business hypothesis in a safe, rapid and lean manner.
Over the years we’ve realized that it always helps to have simple tools to visualize your red time. Visualization helps you understand what’s happening better. And that helps in proactively finding ways to minimize red time.
Simple Design and Testing Conference is an all open space conference providing software practitioners a platform to meet face-to-face and discuss/demonstrate simple design & testing principles/approaches.
At this conference you’ll meet real, hands-on practitioners interested in peer-to-peer learning and exploration. We strive hard to avoid fluffy, marketing talks and other non-sense.
What: Open Space Conference on Simple Design & Testing practices
You’ve heard about limiting WIP (Work-In-Progress) but how good are you at limiting red time? Red time is when you have compilation errors and/or failing tests. A growing group of practitioners have learned how to effectively reduce red time while test-driving and refactoring code. To understand how to limit red time, it helps to visualize it.
In this talk, I demonstrated various strategies to limit your time in Red. We also analyzed a live programming sessions using graphs that clearly visualize red time. Participants learned what development processes help or hurt our ability to limit red time and gained an appreciation for the visual cues that can help make you a better developers and fellow member of the Limited Red Society.
A prioritized user story backlog helps to understand what to do next, but is a difficult tool for understanding what your whole system is intended to do. A user story map arranges user stories into a useful model to help understand the functionality of the system, identify holes and omissions in your backlog, and effectively plan holistic releases that delivery value to users and business with each release.
How do you know you are ready to start iterating? In some cases, very little is needed before the first iteration. In other cases, rushing to iterate (because you were told to) can lead to weeks of time wasted overly focused on delivering a poorly understood product.
In this presentation by David Hussman titled Getting Ready to Produce at Agile Mumbai 2010 Conference, David provides concrete tools for discovering your product context and assessing whether you are ready to start building and / or iterating. Participants learned tools for defining how much process you need and tools for truly understanding what you are building and why, as well as who will use it, why they will (or will not) use it and why.
10 years after the introduction of agile methods, many communities are succeeding in their adoption while others are struggling or failing. Why? Many struggle because agile methods were introduced in an overly prescriptive manner. People were told to follow a set of practices instead of learning to use the agile practices and values to amplify their existing strengths and address their challenges.
In this talk, David Hussman shares successful coaching techniques he uses to grow sustainable agility that lasts beyond the early iterations or the first few agile projects. David begins with a series of tools to help you build a solid foundation: assessments, pragmatic practice selection, chartering and product planning tools. He then moves on to discuss ideas for finding a groove of discover and delivery that is best suited to your project community.
As a full time working coach, David uses coaching stories and experiences to discuss establishing strong cadence while also building the essence of coaching and coaches in your community Whether you are new to agile methods or you are a seasoned players, this session will help you grow your coaching skills and your ability to truly discover and deliver real value.
