Agile and Scrum - How To Make It Work

Agile is about deploying software that delivers business value - faster.

The purpose is not to put points on stories or prioritize backlogs or look at burndowns. Those things support the goal. If they don't you should stop doing them.

The point of scrum is to get the work done that gets you a deliverable that has business value into production in the shortest window possible. (As opposed to a waterfall process that drags on for months before shipping, if anything gets shipped at all).

Your best measure of a scrum team is how often they deploy code, what the value of that code is to the business (ROI on projects) and how much it costs to maintain their software (defects, complexity, error handling). Determine how much time and money the business saves (or pays) after system improvements vs. how much it cost to get them. Savings could be in the form of meeting business regulations so you don't get fined, making people's jobs take 25 less steps, or making information more secure, accurate and timely to get and keep more customers, for example. If you're putting a new gadget on your web site, make sure it's something customers want more than anything else - that will bring you new customers and keep the ones you have. The great thing about web sites is you can test customer response to changes and see what kind of ROI you get. The value of a scrum team is delivering small pieces of functionality in a timely manner so you can measure the response for small changes as opposed to a monolithic project which may sink a lot of money and not deliver the expected returns.

Businesses are about delivering value and making money.

Ultimately this all flows to your business's profit and loss statement, so make sure your measurements are aligned proportionately with their impact to the bottom line.

Here's how to make agile or scrum work

(or whatever you want to call a technical process that delivers value)

...in my opinion and in the little utopia in my head... but also based on some relevant experience delivering business value. I helped a start up grow from $1,000 per month to a multi-million dollar company delivering customer focused software in frequent iterations in ways that minimized cost.

#1 Measure ROI. Determine which teams are producing the most deliverables with the least problems in regular intervals, as well as the value of the deliverables to the business bottom line. Observe. Emulate those teams. (But don't get in their way and distract them while you are doing it.)

#2 Stop scheduling meetings to talk about agile, process and scrum. Discuss blocking issues and share ideas in the two meetings within the scrum framework which are for this purpose - Retrospective and Sprint Planning. The point of agile is to get work done. If you are having lots of meetings to discuss process, agile and scrum outside of these meetings then my personal view is that your company is not agile or using scrum.

#3 Read the guide on scrum.org. Use what works and throw out the rest. Stop trying to add things that aren't in there unless a team asks for them and are proven to deploy more high quality software faster. I should note that the scrum guide changed from it's original form and seems to have been embellished with potentially extraneous meetings (and confirmed by someone who claims to have helped alter documentation at scrum.org). Focus on what gets software with high ROI shipped. Don't get hung up on symantecs. Also note that a lot of consultants are riding the scrum wave and not helping your ROI. A recent thread on the Seattle Java User Group had a lot of complaints about this. Scrum is simple and that is the point. Consultants make it more complicated to charge you more money so you end up with more meetings and nonsense in scrum meetings that detracts from getting deliverables shipped. My sole job as scrum master was canning meetings that were not productive. That is how I help my team stay on track - getting things out of their way they didn't want to do in the first place.

#4 Scrum is about supporting the technical team. If the technical team says something doesn't work for them stop trying to make them do it. Especially listen to the team members that are delivering the most value to the company, not so much the people who are complaining but not getting anything done -- or the people who say yes to everything and aren't contributing what they could be otherwise. They would probably be happy to contribute more if allowed. Stop pretending to be supporting the team with scrum masters - if the scrum masters are only creating disruptions for the team and inserting unneccessary overhead. Listen to the team instead and help when asked and truly needed rather than detracting from progress with extraneous commentary. 

#5 If the team is getting what they want and still not delivering software in a timely manner, either you have a dev lead who doesn't have the experience to design projects for agile deployments (who will learn with time), no leadership or some people blocking the team who are not team players or not good at agile and slowing things down. Perhaps people have personal agendas which are not aligned with business objectives or team success. Make sure you cut through the politics to figure out who is really delivering value. In other words the problem could be the people not the process. Make sure the team can move forward in a way that does not create undue business risk (test and audit everything, have solid team players that know what they are doing and can support those that don't but can learn) and remove impediments - which may mean removing people or adjusting teams to find a good mix of people who work well together and can deliver.

#6 Yes. You need leadership. The leader for implementation of scrum projects should be a technical person if you want to get things done in a timely manner and not have things blow up in production. But your leader can't be a person with a solely technical mindset either. You need to find leaders who understand the value the project is delivering and aligns the technical implementation and cost with the business need. How do you find these leaders? Measure. See #1. Resolve the people issues #5. Some people think there should be no leader and that undermines the person who is the lead. That impedes the overall potential success of the team because it leads to lack of vision and competing objectives. Give your team a leader and back that leader up. If the leader is a good leader, they will not dictate except where there is a potentially dangerous risk or cost or lost opportunity. At that point the leader will press to do what is right for the business and with support the business will win. You can measure your leaders the same way you measure your teams and deliverables - not based on a political campaign, but who delivers value that translates to the bottom line.

#7 Unless you do not care about the cost of the project or the risk to the business, I disagree with letting anyone on the team do whatever they want. If you don't care about the cost of the project or a flawed system go for it. The project can take an eternity if your budget is open ended. Everyone will do their best and you may have to change the code six times but whatever. It may cost ten times more to support it because of poor error handling - or worse. You could be losing money you don't know about. You'll have to catch that through auditing on the business side. So here is where I diverge from the scrum guide. I've had to work until 11:00 PM for weeks to basically re-write flawed software given to someone that didn't have the skills to write it (a prior job). A good dev lead will understand the capabilities of his or her team members and give them work to let them learn and grow - or partition it into pieces within a framework that gives people opportunity without creating undue risk; In other words, without creating a situation where the business has things blow up in production, do costly rewrites, or implement something flawed such as a financial system that doesn't reconcile or a multi-threaded application with a tricky random bug. There are ways to safely structure projects and code and then there's chaos. And yes everyone makes mistakes but keeping them to a manageable amount is better, right? There's also a way to focus on testing instead of dictating - set up tests to determine if each team member's code works or not before you put it in production, rather than dictate how they do things - but if it's a free-for-all those tests are disregarded and bypassed because people can just do whatever they want.

#8. If someone has a new idea try it. Measure it. Test it. With one team. That is open to the idea or is having problems. Don't schedule meetings and training with all teams across the whole company for an unproven concept. Don't force teams that don't want to do it participate if they are functional, happy teams. Every team is different. Let each team do what works as long as within company requirements and getting things done. Let the right team test it - one that can make sure the implementation is efficient and easy to use as possible - if you plan to force it on all teams.  

#9. Continually trying to "improve" processes that are not broken and "solve" problems we don't have adds stress for teams that are trying to focus on getting their work done. Leave functional teams alone. If there is a problem, prove it with measurements to show which teams are delivering the most value to the business - and take into consideration which teams get which projects and why (such as skill or politics). Just because a team is delivering a lot of boring projects doesn't mean they aren't producing a lot of business value. Consider that if you don't hear about a team they are probably doing good work and that's why. But check the stats.

#10. Stop scheduling meetings FOR teams. Teams should be able to tell you when they need a meeting whether for current or future work. Meetings to help non-technical people figure out what the team is doing are the worst. Stop creating separate meetings for projects and work shops and scrum training. There are a handful of meetings in scrum and the team should choose when to have them, not the project manager, backlog owner or scum master - depending on where they are in the process of getting deliverables completed for the current sprint. Because that is the point - delivering software. Let people get work done. Ask the team if they need or want the meeting before you schedule it if the business needs a meeting for some reason. If you have a team of yes-people, check in your scrum tool to see where deliverables for the current sprint are at before scheduling it. Meetings with too many or the wrong people are also a problem. Having business people in a technical design meeting might be fun for the business people but if they aren't needed it's better to have them off gathering much needed business requirements. Business requirement gathering meetings might be interesting to team members but they need to be getting software deployed. Bring everyone together on the business and technical side when there is a true need - such as an early demo of the software to discuss design and requirements where the two sides merge. The team will also let you know when they are ready for more work or stories - and that is a bigger problem - and my next point.

#11. Business people should be focusing on business requirements. Technical teams should focus on implementing them. Define the business rules (not how the screens look or technical implementation) before taking up the team's time. The technical team can't tell the backlog owner what the business rules are - like we only run this process on Tuesdays and it needs to happen before 5 p.m. The backlog owner, analyst, project manager, etc are not the ones who design and build the technical implementation. Stop scheduling meetings for new projects when the business hasn't defined the rules and compliance hasn't signed off on them. Stop writing stories with technical specifications and system design. Do provide the team with the current end to end business process as it exists today before you start showing us the changes - and the changes as business requirements should be to process, not systems. The requirements are from the point of view of a non-technical person - what they see and interact with to support their work flow.  Consider User Experience, not just User Interface. At first I was skeptical of UX thinking it was just another buzzword, but now I am fan. Consider a person trying to transfer money into a brokerage account. They enter their information on a web site. Done right? Not even close. The experience is from the point of the person entering the data to the point it all assets - which may trickle in at different times - and cost basis which may also come later, shows up in the customer's account. That involves the experience of the people that support all of that behind the scenes in both customer service, business operations and possibly third party vendors and contra brokers. And by the way don't forget ALL the scenarios, like the one where the request to transfer goes off to the contra broker and into the ether and never gets completed. If you don't understand scenarios and use cases you are making projects cost more to the business. There are many articles online about these things. The acceptance criteria is what the system users will be able to do (not how or in which system). Think about the value to the user and the business. Define the business process in non-technical terms. The technical team will translate that into a system to support the process.

#12. Use tools appropriately to keep team focused on goal. Some people say people over tools. However if you have lightweight tools it's easy to get a grasp of where a project is at without disrupting the team with extraneous meeting time. Version One is easy to use -- If you keep it simple. People try to over complicate this as well. I'm not a fan of getting everyone in a room to write on pieces of paper or talking about work in general, non-quantifiable terms. And PLEASE don't make us play games and color with markers or do other such goofy things. Project managers like this kind of thing. Technical people hate it. (At least the technical people on my team do.)

Here's how we use Version One:

Two days before upcoming sprint (no meeting!) Dev and QA lead talk team members and divvy out stories. That takes 5-10 minutes. Each person tasks out their stories - at their desk. Assignments can change but it's a starting point. Technical people can equate this to a multi-threaded or distributed process getting things done in parallel vs. a single threaded bottleneck with 10 people in a meeting room. Which will get the job done faster?

On day before or first day of sprint we have a one hour Sprint Planning meeting to review the plan. People can suggest additional tasks and they are added on the fly. Stories can be reassigned or removed from sprint depending on capacity. The other benefit of this is it allows people to have time to think about the tasks between the entering and review. We also hijacked a non-existent field for drop date because QA needs enough time before end of sprint to test if we are going to commit. We fill in release dates if not present for things worked this sprint. There is no need to discuss any of this planning for the upcoming or future sprints in the middle of a sprint unless you are pointing stories (i.e. getting work done). It is a distraction and hurts the team's ability to meet sprint commitments. And it is not scrum. Planning happens in Sprint Planning and Retrospective is for discussing and adjusting your process if needed. I've noticed another long term meeting for planning was added to the scrum guide - if you must have that meeting do it in conjunction with Sprint Planning and don't disrupt the team in the middle of sprint when focused on completing deliverables and put deployment items at risk.

Throughout the sprint the team updates Version One. Story and task status (in progress, done, etc) and hours left. The team also enters release dates and can enter dependencies once they are deep enough into the code to have a technical deployment strategy. Questions about what is in Version One can be asked in stand up if not too disruptive, or addressed to the person the question is for at his or her desk rather than taking up the entire team's time.

Poker Pointing occurs throughout the sprint and we plug story points into Version One - but with the following general rules:

- In my utopia, as has been the case for some projects, we do all our estimating in poker pointing, not in multiple separate meetings for the same purpose. Do it once - it's just a guess anyway and your estimates way in advance will be completely wrong because typically the business hasn't figured out exactly what they want or gotten sign off from all the appropriate people (which then leads to re-estimating and worse if code is started - rewriting).

- Sometimes we revisit and re-point stories if they have changed significantly.

- QA is typically blocked waiting for Dev drops in the first half of a four week sprint so poker pointing is best in the second week of the sprint if things are going well, or possibly third if not so well. Perhaps you wait until everything made it through RC because QA is also slammed in the third week and your deployment is at risk. The team may choose to have a few long poker pointing sessions at the end instead - especially if you have stories in a good state and/or enough points for the upcoming sprint. (Refer to the statement at the top of the article.)

- If your team is slammed consider if you have enough points for the next sprint, in which case you might not want to disrupt and cause the current deployment slide for the sake of poker pointing. (Again, refer to the goal at the top of the article).

- We try to make sure the stories are ready to point before poker pointing and that we have enough of them. Because I currently work with the world's greatest analyst this is generally not a problem.  All team members can review stories before poker pointing if you have issues with this or just your leads to make sure stories are ready before dragging everyone into a room and disrupting their work.

Project managers and backlog owners can look in Version One any time to see the status of the project - instead of scheduling a meeting and disrupting the team. More time can be spent doing work instead of talking about work. If the business people want to know about specific stories or blocking issues, come to stand up - don't schedule yet another meeting. Additionally all the information in Version One can roll up into reports for business showing where projects and teams are at and upcoming work. Stop creating separate spreadsheets, reports, emails and busy work. Create automated reports from Version One that gives business the decision points they need to run the business cost-effectively and profitably with minimal work for the team and less disruptive questions to teams trying to get work done. See #13.

#13. Measure. This is so important I will say it twice. Looking at Version One but more importantly what gets delivered each sprint is far more accurate than scheduling a meeting without looking at the facts and hearing the old "we are 90% complete" line. If the team says they will meet commitments and there are 20 hours left in the sprint but 60 hours left in Version One to do you can avoid a meeting which is only going to make it worse, and address the issue in retrospective and Sprint Planning. Measure production incidents, business value in terms of cost savings, increased income and profitability, new customers, and whether more work is getting done with new systems (as opposed to making things more cumbersome). Some systems create more work but deliver value by increasing assets, revenue, or reducing risk. You need someone who can measure appropriately - not just throw out numbers. 

#14. The project needs to end. Agile doesn't lend itself to this concept very well without proper planning. This can be a downfall for agile when people don't understand how to make it work. You can think of agile projects as time-boxed. You have a list of things to get done and a budget. You'll get as many things on the list done as possible within that budget. The more up front planning you do and the more time you give your team to focus on deliverables, the more items in the list will get done. You don't have to have every screen designed at the start if the design is flexible, but you need your high priority business rules and processes documented and signed off on by decision makers and compliance before you start. New requirements = increased scope and cost in most cases. Incomplete decisions = project delays and increased cost. You need someone on the team that understands how to prioritize deployments to deliver business value early on and in a manner in which the project can be cut off at any point and not be a total loss. If you have high priority deliverables make sure they get deployed early and leave the nice to haves at the end. The other nice thing about deploying possibly incomplete but functional initial deployments is the ability to minimize risk (run old and new components in parallel or release non customer facing side first) and to get feedback before the targeted end of the project so you have time for changes within the project window.

#15. Remember why we have jobs. Ultimately the measurement of our work boils down to financial statements - profit and loss. If the business is doing well, we keep our jobs. People who drag entire teams into meetings to talk about work instead of doing work aren't focused on improving the bottom line. People who are constantly hopping on the latest buzzword bandwagon but don't understand the cost and value to business aren't really going to help your company in the long run. People on teams are happiest when they are productive and add can value to their full potential. Some have more potential than others perhaps, but everyone can be an important contributor to the overall workings of a company if they focus on the right things. They want to help your business grow. Let them. It will help the bottom line and lead to a more successful company - if you have the right people. The right people understand why we have jobs - because we are paid by a business that needs to make money and be profitable to do so. So I'm back where I started.

Agile is about deploying software that delivers business value - faster.

So get out of that meeting, walk to someone's desk to get your question answered, and get to work!