If your team follows a traditional, legacy approach to software development and wants to convert to an agile approach, how should you go about it? Let’s say you want to convert from a waterfall approach that uses a strict command-and-control model to Scrum that uses a self-organizing team model. How would you get from here to there?
There are many ways to undertake this change. None of them are quick or simple. Small organizations are more likely to succeed than big ones simply because they have less invested in the status quo. Big organizations have much to protect and preserve.
Here are two extreme examples of how you might proceed:
- Dump everything you’re doing now and adopt all new techniques. Don’t consider anything sacred or untouchable. Change everything.
- Change one thing, try it out, let it settle, then change something else. Approach the switch slowly and deliberately.
Which option is better? Which option will produce the better outcome? It’s up to you.
Advantages of #1
- Gets all the pain and discomfort out in the open immediately. Lets everyone know what’s going to change.
- Allows the team to focus in building competence with the new approach. There’s nothing to preserve.
Disadvantages of #1
- Causes maximum disruption which might jeopardize a product or service release.
- People may get confused and frustrated increasing the odds of the new approach failing completely.
Advantages of #2
- Minimizes the pain and discomfort making the transition manageable.
- Allows the team to focus on just one aspect of the new approach at a time building expertise as they go.
Disadvantages of #2
- Spreads out the pain and discomfort over a long period of time creating a difficult work environment.
- Increases the odds that the new approach will never be fully implemented.
If you select #1, be ready for plenty of turmoil. Offer lots of support, training and coaching. Be willing to accept some small failures and some employee turnover.
If you select #2, be vigilant. Keep pushing new ideas and new techniques. Do not accept “good enough”. Keep marching toward the final goal.
I have good days and not-so-good days. I’ll bet you do too. My good days are the ones that leave me feeling a sense of accomplishment. That happens when I get something done — finished, not just “worked on”. My bad days are the ones that leave me wondering what I did all day.
You see, it’s not simply a matter of being busy. I have a lengthy backlog of work — more than I will likely ever finish because it seems to arrive faster than I can finish it. I’m always busy but I crave more. I need to be done. I need to finish stuff.
If you’re like me in this regard, and I suspect you are, your job satisfaction and productivity have a direct relationship to how much work you get done — that’s finished, acabado, fini, finito, fertig, consumandam. How often do you hear people bragging about what they spent time on? Rarely, right? They brag about what they accomplished. What they completed. What they got done!
We all need more good days. People are energized by finishing. We derive job satisfaction from finishing a major task — accomplishing something of value. All of us should be finishing something significant every day — every single day.
Another Reason Why Waterfall Doesn’t Work
That’s a huge problem for software developers in traditional development organizations. They are forced to spend days, sometimes weeks, working on documents and diagrams. After all that work, they’re forced to wait for some bureaucratic approval process to complete — it’s hurry up and wait all over again. Or, they may be forced to summarize the documentation in a PowerPoint presentation and deliver it to a committee. As each day passes, ‘just shoot me now’ becomes more and more appealing.
Productivity declines. Output volume shrinks. Quality suffers. Managers are oblivious because people appear to be busy as progress is being recorded in weekly status reports.
The secret to better morale, improved productivity, and superior results is unbelievably simple. Let your teams finish something. Note the word ‘finish’. I didn’t say “do something”. I said “finish something”! Stop creating busy work. Dump the approval cycles. Remove the impediments.
In addition, when your team needs something from you such as an approval or an upgraded development tool, make it happen. You’re putting a lot of pressure on the team and some of that pressure will push back on you. It’s only fair that you respond quickly.
Improving morale isn’t brain surgery. It’s common sense. To create more good days define simpler accomplishments, remove impediments and get out of the way.
I don’t know about you but I hate to fail. I’m not kidding. I REALLY hate failure. And that is one of the scariest aspects of agile software development. To succeed, you have to be willing to tolerate failure. In fact, if you’re not experiencing any failures, you’re not pushing yourself or your team hard enough.
Understand that I’m not referring to monumental failures. No one wants to see their million dollar product launch fail. (I don’t even want to see my $1,000 project fail.) That’s why agile principles encourage us to fail fast. Those quick failures tend to be small and relatively inexpensive. They are learning opportunities that help us avoid the big failures — the catastrophes.
Take a chance. Try an experiment. If you’re unsure about an approach or a technique, give a try. Run a test. If it fails, you haven’t invested much time or money so there’s little waste and no harm. It’s a lot better than spending days writing, reviewing and revising documents hoping that you haven’t missed anything.
Use Real Data
One area where you have to be extra vigilant lies in the data set used for your tests. You may get a favorable trial result using limited or artificial data inputs. When the software is deployed to a production environment with 1,000 times more data and many more boundary conditions, what worked in development may crash and burn.
I’ve seen this happen many times over the years. Software that responds instantly in development slows to a crawl in production. Or the software handles the artificial data set cleanly but when presented with real business data, numerous failure points are exposed.
Develop and test with real business data if you can. If time and money don’t allow for replicating the business data in development, do a trial production deployment. Be absolutely certain that you can back out whatever changes you make and restore the prior state quickly. It’s also a good idea to instrument the software. In other words, add extra logging and tracking functions so that you have good information for analysis in the event the trial fails.
If things go smoothly, you can re-deploy without the logging and tracking functions or, better still, simply turn off the logging via a configuration parameter.
Failure doesn’t have to threaten your career or bankrupt the company. Take prudent risks. When things don’t turn out as you hoped, learn, assess and try again. That’s agile!
Software developers, testers, analysts and managers are known to be detail oriented. We need to know exactly what needs to be done so we can devise and implement software algorithms. We need answers to detailed questions so we can make the right implementation decisions.
Meanwhile, business people don’t always have all the answers. This is particularly true for new business initiatives. These are often experimental. They represent learning opportunities. If the business teams had all the answers, would they need high-caliber (that is, expensive) software people?
Business Really Matters
I work with multiple business groups. They often ask for new data elements or new software algorithms. Sometimes they know exactly what they want and what they’ll do with the information. Other times, they only have a rough idea. The actions they’ll take after seeing the results depend on the results they see. The analysis will, in turn, generate new requests for the software team.
These situations are more common than not. Running a business is not an exact science. It demands flexibility and rapid responsiveness. Whenever I direct questions to the business stakeholders and receive answers that are vague or general, I work with the development team to assure that the software can flex with the business.
For example, if someone tells me that are interested in data elements within a broad range of values, I’ll make sure the range can be changed by simply editing configuration parameters. If someone gives me a list of data elements, I’ll make sure the list can be changed by updating a configuration table.
Does your team seek out ways to do less?
Part of being agile is designing software for change. These types of configuration changes should be normal operating procedure. They aren’t technical changes and don’t require change management or backlog grooming.
Take a look at your backlog. Look for ways to combine stories or eliminate the need for some of them entirely. Doing less is a perfectly valid way to deliver more. The alternative is to slow down the business and that’s a dreadful outcome.
I’m hearing and seeing the word ‘agile’ more and more around the office. It comes up in hallway conversations and management presentations. Managers have gotten the message and want us to be more agile. That’s great, right? So I ask them what it means to be more agile and the answer I get is rather vague.
It appears to come down to doing more frequent software releases where each release includes incremental enhancements. I don’t hear anything about changing the underlying development process, currently waterfall for most parts of the IT department. Is that all it takes to be ‘agile’? Just release more often?
And so it begins…
This is frequently how the agile conversation starts in big companies. Senior managers decide to be more agile in their approach to software development. They define the word agile however they choose. Their choices are usually founded on protecting much of the status quo and keeping changes to a minimum. Their goal is to improve, not reengineer.
The end result is often smaller and shorter waterfall projects. Granted, this approach reduces risk, which increases with time. So if risk reduction is the primary goal, the technique makes sense — but it’s not agile software development. It’s not even a first step toward using real agile development.
This is how agile approaches using the techniques of Scrum, Kanban, XP and/or Lean get a bad rap. Any software development approach can be called agile. It’s simply a label. Take any development process, make a few tweaks to address perceived shortcomings, and your team is agile — well, at least it’s more agile than it was.
Waterfall in disguise…
However, nothing changes fundamentally. The teams still produce lengthy business requirements documentation. They continue to generate functional and technical specifications. They leave their change prevention — sorry, change control — process in place. They leave the testers out of the loop until the final development stage.
They may achieve some incremental gains as a result of reducing risk. The success rate of projects may increase (depending upon how one defines success). But important questions remain…
- Have the relationships between technical and business people improved?
- Are the stakeholders and user representatives actively engaged with the development team?
- Are lead times shorter for new feature requests?
- Is the quality of the software better?
- Are the software users/buyers delighted?
Take my advice. Stop focusing on the process. Start focusing on the users.
Many managers are fond of using metrics as a way to evaluate the performance of software developers. This can be done both at the team and individual levels. However, most metrics can be “gamed”, that is, manipulated to show the desired result.
Some readers are likely thinking that their teams would never “game the system”. It’s true that most teams would never openly conspire to change a metric result. However, in the end, people will do whatever is needed to protect themselves, their teammates, and their families. If management places the team under severe and unreasonable pressure to improve a metric, each member of the team will seek out ways to improve.
Here are a few examples of metrics that are fairly easy to improve:
- To increase team velocity, increase the size of user story estimates.
- To improve the pass/fail test-case ratio, avoid testing boundary conditions.
- To reduce the size of the backlog, put fewer stories in it.
- To produce more lines of code, write sloppy code.
- To complete more tasks, divide the work effort into smaller tasks.
- To reduce time-to-market, write less software and/or reduce testing.
- To reduce your development costs, take on more technical debt.
These tactics may appear dishonest but it’s a matter of perspective. If I make a demand that most people view as unreasonable, I should expect that those people will satisfy the demand using equally unreasonable tactics. Fair is fair, right?
Focus on the right things.
One way around gaming is to track multiple opposing metrics. For example, you could track velocity and average story size over time. If velocity improves while story size increases, something is out of balance. But what problem have you solved? How has the company benefited?
In the end, metrics are internal measures of the past. They tell us how we did recently versus how we’ve done historically. The problem is that our customers don’t care. They want software delivered as promised; software that does what they need; software that works well; software that’s a delight to use.
The only valuable metric is your customer’s opinion of the software. That’s why the principles of agile software development make so much sense. Focus on customer collaboration and working software. Focus on the future. Use metrics sparingly to help identify and correct team weaknesses.
Metrics have their place but not as the team’s focal point. They are tools not outcomes.
I feel compelled to weigh in regarding the recent decision by Marissa Mayer, CEO of Yahoo!, dropping the company’s work-from-home option beginning in June. Yahoo will require that employees work in an office location (unless they have a need to work from home such as a visit by the “cable guy”).
Firstly, I have to say that I’ve never worked at Yahoo nor do I know anyone who does. Also, I’m sure that most Yahoo employees work hard and earn their pay. That said, Yahoo has problems — lots of them. The company is in serious trouble. It’s relationship with Microsoft has not gone as well as hoped. The company lacks a clear identity. What is Yahoo’s strength? What is it good at? Why would you use Yahoo rather than another website? I don’t know the answers to those questions and that’s a problem.
According to Business Insider, Mayer made the decision after reviewing VPN (Virtual Private Network) logs. Simply put, many more people claimed to be working from home than were logging into the corporate network via VPN. I have to agree that if you’re working from home, you should be signed into Yahoo servers and collaborating with colleagues. If management oversight was lax, abuses were likely and something needed to be done.
The core issue is poor management.
This is clearly a management problem. Think about it. Employees are “working from home“. Some are not logging in. Work is not getting done. How would you fix that?
I’d hold people accountable. Managers should assign specific tasks or employees might grab them from a task board or a list. Either way, tasks should have due dates and the person working on a task must be held accountable. If impediments arise — and they often do — the employee is responsible for raising awareness of the impediment and seeking assistance. In other words, impediments are not an excuse for failing to deliver by the due date.
If this sounds like “management 101“, it is. Will dragging everyone into the office help? Not likely. Poor management will still be the root problem. It will be exacerbated by having disgruntled employees. Things are going to get much worse at Yahoo before they get better.
It’s sad. Yahoo is one of the original and premier Internet companies. I’m sure Mayer is frustrated and stymied. She had to do something significant to get everyone’s attention and force the organization to change. This is a quick and dirty approach — clear and simple.
I wish she had opted for a more complex change such as laying out a company-wide product roadmap and holding everyone accountable for achieving it. It’s not too late. Hopefully this new work-at-the-office policy is merely a stopgap measure.
(BTW: This issue goes far beyond agile software development and collocated teams. Yahoo’s problems run much deeper. This is an attempt to change a stagnant and dying corporate culture.)
Several studies have shown superior software development success rates when using an agile approach like Scrum or Kanban versus a waterfall approach. Does using a waterfall approach to develop software cause many projects to fail? Conversely, does using an agile approach cause projects to succeed?
I wish it was that simple. Ultimately people cause projects to succeed or fail. People are drawn to people like themselves. People are drawn to environments and cultures they prefer. What characteristics do you look for in the people you hire?
Waterfall approaches to software development are prescriptive. They use command-and-control, phases, gates, documents and approvals to get things done. What kind of people, do you suppose, are attracted to those techniques?
Agile approaches are collaborative. They use teamwork, self-organization, conversations, visuals and feedback to get things done. What kind of people, do you suppose, are attracted to those techniques?
Real Change Takes Time
I’m not a psychologist or sociologist so I’m not going to attempt a deep dive into these ideas. My point is that if you want to improve your software development results, you need to take a hard look at the messages you’re sending and the people you’re attracting.
Why is this so important? If you decide to change your development approach, you’ll need to change your people too. How are you going to do that? It won’t happen in a sprint or two. It will likely take a year or more to completely transition from one approach to another.
In a large organization, you’ll have multiple development teams. Are they all going to transition at once? If so, it will be a huge undertaking. If not, how will interteam dependencies be managed when one team is using Scrum and the other is using waterfall? Their deliverables will not be aligned.
Adopting agile software development is not simply a matter of changing the rules — you need to change the entire game. What would you do if you wanted a basketball team to play ice hockey? How about a soccer (football) team converting to basketball? It would be a colossal transition requiring plenty of training and conditioning. Some players would not be able to adapt. New players would need to be recruited.
That’s what you can expect when going from a traditional, prescriptive, software development approach to Scrum or Kanban. You can make it work if you’re willing to invest the time and effort. Do you have the time?
In this post, I’m sharing a technique for writing a software module with you. I’m assuming that we are implementing a user story and that the acceptance criteria are clear. The story has been divided into a set of tasks and the task durations are known.
It’s an approach that works well for me though your mileage may vary. I strongly urge you to refine and tune the approach to your needs and most importantly, to your work style.
If you’ve ever had to write a report, proposal or even a specification, you may have heard advice like the following:
- Establish a time interval, say 10-15 minutes and set a timer.
- Work on the outline.
- Get your major thoughts written down.
- Don’t think too much, don’t analyze, just write.
- If you get stuck on an item, skip it.
- When the timer expires, go back and organize what you wrote into sections or chapters.
- Reset your timer for another 10-15 minutes.
- Write a section until the timer expires.
- Forget about grammar and spelling, just write.
- Go back to step 7 and repeat for each section.
- Now go back and do some editing for grammar and spelling.
- Make additional passes as needed until the document is complete.
What does this have to do with writing software?
Of course, writing software, in any computer language, is more complex than writing a report, proposal or specification. It’s not necessarily more difficult. It’s more disciplined. There are many more rules to follow and external dependencies to worry about.
Despite the added complexity, you can follow a structured approach like the one above. Let’s say you’re implementing a user story. You’ve likely broken it down into a set of tasks. You should have a rough idea of how long each task will take. Many developers will approach the story implementation serially. That is, they’ll work through the task list sequentially.
I do it differently. I iterate over the list of tasks. Here’s a basic approach that you should customize for your situation.
- Establish a time interval, say 25% of the total estimated story implementation time, and set a timer.
- Create a skeleton of the code (there may be 2 skeletons — one for test code and one for the story).
- Get the major sections of the code defined.
- Don’t think too much, don’t analyze, just create the structure.
- If you get stuck on a section, skip it.
- When the timer expires, go back and review what you wrote. Note any areas that need more thought.
- Reset your timer for 25% of the story time divided by the number of code sections you have.
- Write a section of code until the timer expires.
- Forget about covering every detail (e.g. error conditions), just write.
- Go back to step 7 and repeat for each section.
- Now go back and do some editing, testing and debugging.
- Make additional passes as needed until the code is complete.
The approach will vary depending on the situation. For example, if I’m unsure about how something might work or if it can even be done in the manner I’m thinking, I’ll make a first pass targeting the area I have questions about. Once I get that ironed out, I’ll build out the rest of the code as described above.
There you have it — a simple iterative technique for writing software modules. Give it a try.
In the world of agile software development, there’s a lot of emphasis on things like story estimates, daily standups and team retrospectives. Those things are important but there’s a serious problem that none of them address — feature set. What features should the software have in the next release?
Waterfall development practitioners tend to include everything they can in their requirements specifications — if anyone requests it, put it on the list. Is it any wonder that those software projects take many months or even years to deliver anything of value?
Agile development practitioners talk about minimums — minimum viable product (MVP) or minimum marketable features (MMF). Both concepts appear reasonable but a critically important question is left unanswered. How is the minimum determined?
Try a Simpler Approach
The simplistic answer is that it’s up to the product owner. Someone has to have the final say, right? Feature requests come from many sources including software developers, product managers, marketing experts, senior managers, and customers. Every one of them has a unique perspective and different needs. The product owner can help sort it all out but it’s never easy.
Let’s not forget the adage that people often don’t know what they want until they see it. The PO may spend many hours deriving MVP or MMF only to find out later that customers (the only opinions that really matter) either disagree with the choices or changed their minds.
I suggest approaching feature prioritization as an iterative process. Don’t devise elaborate priority matrices or scoring systems. They are confusing and subject to manipulation. Instead, take all the features of interest and let the sponsors, stakeholders and end-user representatives classify them using just two categories like:
Let everyone know that only features marked vital have any chance of making the next release. In the unlikely event that the vital feature list is short enough after one pass, you’re done. If not, you’ll need to repeat the process using the vitals only. If the list is still too long, do it again.
If you get stuck, that is, everything left is vital but there’s too much to do, let everyone know that the PO will make the final decision. Once the list is final, there is still one thing left do to.
The development team needs an opportunity to review the final list and look for inter-dependencies. For example, vital feature ‘A’ may require that non-vital feature ‘Z’ be implemented. Don’t skip this step!
- June 2013 (8)
- May 2013 (13)
- April 2013 (13)
- March 2013 (13)
- February 2013 (12)
- January 2013 (12)
- December 2012 (7)
- November 2012 (11)
- October 2012 (12)
- September 2012 (8)
- August 2012 (11)
- July 2012 (13)
- June 2012 (12)
- May 2012 (13)
- April 2012 (13)
- March 2012 (13)
- February 2012 (12)
- January 2012 (13)
- December 2011 (12)
- November 2011 (12)
- October 2011 (13)
- September 2011 (14)
- August 2011 (18)
- July 2011 (13)
- June 2011 (18)
- May 2011 (19)
- April 2011 (16)
- March 2011 (21)
- February 2011 (20)
- January 2011 (22)
- December 2010 (21)
- November 2010 (16)
- July 2010 (2)