You are on page 1of 6

Software Development Process Improvement for Enterprise Sustainability

Why Scrum, Agile and Lean? By Rod Claar, Principal Consultant Effective Agile Development LLC May 2009 Part 1 Considerations in Software Development Process Improvement There is a lot of information out there about why an organization would attempt to improve their software development process using any of the wide variety of methodologies, techniques, systems, coaches and mentors that market their message. In fact there is so much information it is overwhelming to anyone genuinely trying to improve their process. I've been out in the trenches for several years now and have seen many different approaches used with varying degrees of success. In fact no two organizations have ever done the same thing or had the same results. My goal with this article is to try to lay out a thought process and an approach that can be fit to nearly any organization. Every organization is different starting with the people. The combination of people who are the stakeholders, business managers, customers, developers, support staff, project managers, product managers and testers all contribute to the collective abilities, knowledge, fears and tendencies. These people tend to frame andconstrain the productivity of the organization and the process elements that are available and how effective they will be. How your organization applies principles and practices of Scrum, Agile and Lean will also be impacted by your organization, it's people and it's culture. Your path to process improvement will unique to your organization. Process Improvement However we must start with a definition of process improvement. There are as many ideas about what this means as there are methodologies being promoted. A software development project is in fact a product development project. The sponsoring entity is authorizing the expenditure of time and money to create something and this decision has been one of prioritization choosing to dedicate the resources to this project rather than other projects or doing nothing. Doing nothing is a choice, but more on that later. This decision of what to do, if anything, has been driven by a wide variety of considerations and points of view. Countless MBA programs, process experts, Effective Agile Development LLC Copyright 2009 Page 1

economists and business people have studied this problem and issued their idea on what should be done next in an organization. One popular method is First-In / First-Out scheduling. This system relies on the knowledge and wisdom of the stakeholders requesting solutions. The one thing that this method has going for it is that it is simple! However if the stakeholders are not in possession of complete knowledge of the situation and are not acting with a broad perspective selflessly, the wrong priority will be assigned to work. A variation on FIFO is working on the important stakeholder's top priority. This person may be the loudest right now, or worse yet the organization chose to do something else previously and now feel like they need to appease this stakeholder. Might does not make right! Just because someone is loud and possibly annoying does not make them right or wrong. A step in the right direction is to create an annual budget and plan for the items that will be worked on in the coming year. This one is really a budget driven process and most of the time significant effort is required to create the proposal and estimate for time and resources. If the world is not going to change in the next year ( and we are certain of that fact up front!) and we have all the knowledge and insight required to create an accurate estimate, this one will work just fine! The world will change TODAY so the annual plan is wrong by at least the delta of change. Sometimes a plan is completed and a project is started because the analysis required to authorize the project was previously done. This one can really lead to poor choices. If something was analyzed in the past and something else had ahigher priority it does not mean that the one left out of the plan before now disserves any prioritization. Additionally the analysis has grown stale and may now be completely wrong given current circumstances. Every organization has competitors. The competition is for resources, money and people. If your competition is doing something new or better than your organization, you need to be paying attention and reacting. However just copying the completion in me-too fashion is not always the correct approach. Can you expect to catch up and overtake your competition with me-too projects? There are other factors that tend to come into play in these examples. For instance many project teams are drawn from matrix organizations. The groups or departments that supply the various disciplines have their own agenda and budget. This can lead to the selection of projects based on the balance of available discipline resources. This is like when my mother sent me to the store to get a couple of ingredients for something she was cooking. I must have been about 7 years old. She gave me more than enough money but she did not tell me what to do with the rest of the money, so I spent it on things I wanted!

Effective Agile Development LLC Copyright 2009

Page 2

Many organizations also have rules or culture that dictate full up-front planning and full, complete project delivery. Both of these practices, while probably driven from good intentions, do not take into account the change that will happen and the fallacy of trying to figure out something at a point in the project when you know the least about it. All of this leads to goals that may be off the mark. Consider these statements ... "Project Scheduling will be done so that all team members are working on something in the plan." "We better work on Joe's project or he will complain to the VP of Development." "All project funds must be spent by the end of the year!" "I'm not sure what is important, but this project will be more fun that the other!" "Our #1 competitor has just announced the release of a feature that our customers have been asking for. Keeping up with the competition is critical." "The audit has determined that inventory shrink was unacceptable last year. We must have a better inventory control system by the end of the year." "If we add this list of features, in addition to the basics, our market perception will be better when we do release." I'm sure you have heard variations of these statements. Unfortunately, all too often the real goal is the justification of our job, team, department, project or company. This approach has never been appropriate and in today's economy it may well be counterproductive. What is wrong with these ideas and approaches? You've heard the saying that they could not see the forest for the trees. What this means is you are lost in the details and have lost sight of the big picture. What is the big picture for a product development team? Obviously there is some business reason for the project and the business believes that it can achieve its business goals faster and/or cheaper with an internal project team. In most cases there is a Return on Investment (ROI) analysis that resulted in the conclusion that it is a good idea to deliver some business value using the money, time and people available to the organization. This is really a two part decision. The most important one relates to the project itself. Given the assumed value to be generated by the delivery of some set of business capabilities it would be worth some financial investment to get those capabilities at a certain time. The other decision is how to execute on that investment. If an organization decides to establish and maintain a software product development team, it has decided that this is the most efficient way to get what it wants when it needs it. Even for a small team this is a significant commitment and there is a certain cost to starting and maintaining the team. In Effective Agile Development LLC Copyright 2009 Page 3

other words, the decision to develop these business capabilities internally is an investment and return decision also. Part of this analysis is also very often related to the accuracy of the understanding of the requirements that is achievable by an internal team. The vast majority of projects today are very complicated and often involve new technologies and new markets. These factors contribute to the risk of project / product failure. Many organizations conclude that an internal development team can mitigate these risks. Many organizations also choose to develop software internally to protect the internal Intellectual Property (IP). Whether the software is a component of the product or is a tool used to market, deliver or otherwise monetize the product, the protection of the IP with an internal team is very common. What Should We Focus On? This leads me to four things that most software product development teams should focus on. 1) The delivery of business value quickly. This is the main point of doing the project and maintaining the team. Delivering the value late or slowly reduces the ROI and may undermine the business and the value of the team. 2) Get quick feedback to validate the course and the solution. Projects that are successful depend heavily on feedback to insure that the solution really meets the need. Delivering the wrong solution or a poor solution impacts ROI. 3) Deliver the business value in a repeatable and sustainable manner. If the organization has decided to establish a development team, it expects to have repeatable, sustainable delivery of business value that delivers ROI. If the Pony Express had overworked and abused the horses, its business model would have been impractical. 4) Delver software solutions that add value now and do not slow down the delivery of business value in the future. Focusing on delivering increments of business value that can be built on and maintained efficiently is a required element of long-term enterprise sustainability. Part 1 Conclusions The goal of improving the software development process in any organization must be focused on the delivery of business value in such a way that it creates and acceptable return on investment and enables the future delivery of business value.

Effective Agile Development LLC Copyright 2009

Page 4

The clear statement of this goal is a primary responsibility of the business leadership. Leadership at the highest levels should regularly require evidence that business value is being delivered with a focus on current and future ROI. Product and project leadership should create a vision for the product based on acceptable ROI business value delivery. Teams should be evaluated and rewarded based on the delivery of business value that delivers acceptable ROI in a sustainable manner. Individuals should be organized and managed with the primary goal of increasing their productivity and job satisfaction through teamwork and team goals. The questions remain. How does an organization identify business value opportunities in such a way that the capabilities can be delivered in a timing and a cost that deliver real ROI? How do the small team practices of Scrum, the code quality and analysis practices of Agile and the efficiency and focus of Lean be used together to deliver ROI? Part 2 will look at the basics of these three often touted methodologies and see how they can and should work together to help achieve enterprise sustainability. The Role Of Scrum Scrum is a small team process structure. It is about the small team of less than 10 fully dedicated individuals who possess the skills required to deliver the desired business capability. Scum supports communication, teamwork, shared responsibility, team health and efficient and effective work practices. While there is a common set of practices, artifacts, meetings and roles, the process itself belongs to the team and should be modified to help the team achieve the goals it has established. Using a commitment based approach to setting iterative goals the team delivers demonstrable software on a regular basis. The team is allowed and encouraged to deliver software with quality that is extensible and maintainable over time. A business focused person, referred to as the Product Owner, establishes the vision for the product and maintains a prioritized list of business value delivering items for the team to work on. The Product Owner is responsible to the business for the appropriate prioritization of the capabilities delivered by the team. The organization provides an advocate for the team to look out for the health of the team and help the team manage and improve its process. This Scrum Master is the primary guardian of team sustainability. Using the iterative and incremental foundation of Scrum the Product Owner prioritizes the team goals, provides clarification of business goals and acts as the final acceptor of the capabilities delivered. The Scrum Master acts as a counter Effective Agile Development LLC Copyright 2009 Page 5

balance to the product needs helping to improve productivity by reinforcing the team's practices and pointing out impediments to current or future productivity. The team commits to deliver specific goals on an iterative basis and provide demonstrable software in short iterations.

Effective Agile Development LLC Copyright 2009

Page 6