The Goal: From Light Bulb to Live
Regardless of the process employed, the goal is the same: take the idea in someone's head and develop it into live, production-deployed software. Whatever process can achieve that goal in the shortest time, with lowest cost and highest quality, is the one we should strive to adopt. This process also needs to comply with numerous enterprise constraints which can come in a variety of forms: distributed teams, compliance to standards, and records for auditing just to name a few.
Agile: What's In a Name
What's great about naming a method after a desirable trait, at least from a marketing perspective, is any method without that name implies the absence of that desirable trait. So if you are not using an agile process, it would seem you are using a non-agile process. And if you are using a non-agile process, then you are not agile! Of course, this is flawed logic and a fallacy. There are many ways to achieve light bulb to live, and whatever way is chosen needs to balance a variety of factors. One of the more important aspects to balance is the anticipation-to-adaptation ratio.
Going Shopping
If you happen to live a good distance from the city because you enjoy the natural beauty of the country, then you probably have gone through the exercise of preparing to go into town for shopping. Knowing that getting to the store and back is an investment in and of itself, you may spend a little time preparing a list of things you need to purchase before you even get in the car. A little forethought before the trip will certainly pay dividends in not having to make expensive, multiple trips to the store. However, the list may not be entirely complete and you may need to buy some things not on the list once you get to the store. Staying strict to only what's on the list could end up being as inconvenient as not having a list to refer to in the first place. Therefore, having both anticipation and adaptation is required for a successful trip.
Process Myths
Myths come from both agile and traditional advocates. One myth promoted by inexperienced Agilists would be that in the above example, as a Traditionalist we would spend so much time on the list that we'd starve to death before getting to the store. And uninformed Traditionalists would argue that as an Agilist, we would make so many trips to the store that we'd run out of gas and be stranded on the side of the road - precisely midpoint between the store and our home! Neither of these myths has merit. The real issue is in formulating a process and set of practices to help optimize anticipation and adaptation for our organizations.
Process Evolution and Moore's Law
Just as airplane simulation software can be much more cost effective than real-world flights, continuous integration and frequent delivery are two Agile practices that can save us time and money when compared to longer release cycles and large integration practices reserved for the tail-end of the project. Why didn't we think of this before? How can we be sure we haven't?! There needs to be a certain level of technical maturity for the economics of our practices to make sense. Today, we have commodity hardware and inexpensive development tools that enable and encourage such practices. This was not always the case. Our computing platforms used to be quite expensive with departments competing for time on the mainframe to run programs. And development was more time-consuming as well. Back then, it made sense to spend more time in analysis and design before incurring the expense of running the program.
Our Position
"Everything should be made as simple as possible, but no simpler."
We have worked primarily with large organizations that have dozens if not hundreds of staff contributing to the development of enterprise systems. These companies have distributed teams, multiple standards-compliance objectives, as well as third-party contracts that need to be upheld. This work has certainly influenced our position to be one that is not idealistic nor dogmatic. We embrace the overall philosophy of the Agile Manifesto and look to keep process and ceremony as light-weight as possible, but no lighter. We need to go from light bulb to live while at the same time, embracing, not fighting, the real constraints of the enterprise.
Recommendations
Manage a project by user-stories or user-goal-sized use-cases rather than tasks or "the system shall' types of requirements documents. Doing so allows us to deliver whole, not partial value to the organization and also allows us to prioritize functionality. The features with the highest priority will be delivered first.
Embrace story-point estimates for releases and then refine those estimates into time-based estimates for the tasks in iterations. Our go-to reference for estimating and planning is Mike Cohn's excellent Agile Estimating and Planning. It is an incredibly useful resource and will certainly debunk the myth that there is no planning on an Agile project.
Leverage the Rational Unified Process (RUP) where it makes sense. RUP is actually a meta-process. It doesn't come out of the box ready to deploy. Instead, it offers a set of building blocks that can be used to build a custom process for the organization. Its power is its weakness. The drawback of the approach, and why we think it hasn't succeeded nearly as much as some of the Agile approaches that followed it, is this: if something is built to be configured, it will be configured, and it will most likely be configured incorrectly. An organization looking to implement RUP for the first time will have its hands full. And yet, RUP provides many great techniques and tools that can be helpful to an enterprise. One we use in user-story development is the explicit identification of common vs. non-common paths borrowed from use-cases. We also make extensive use of design-level class diagrams.
Keep user-stories and other requirements in a tool, preferably one that supports the creation of additional structure through a formalized set of tags. This will ease navigation (for what could be a "sea of stories"), provide convenience to multiple stakeholders, and help facilitate distributed teams.
- Deeply experienced in a variety of methodologies and can customize a methodology to best fit your culture and organization.
- Trained and coached many clients in the use of RUP, Scrum and agile practices.
- Members of the Scrum Alliance.
- Certified Scrum Masters.
