The Art of Agile Development

Keep this book to hand

The Art of Agile Development was recommended to me by Jeff McKenna when he provided some Scrum coaching to those of us in the Dublin office working on Oracle Social CRM. Back then it was a new, hot off the press book, but I have recently reread it because I have found it useful in providing guidance on what to watch out for when changing agile development practices. This was necessary due to changes in teams and technologies as some of us focused full time on Fusion Applications. Practices, roles and responsibilities we had gotten used to had to be adapted or dropped to blend in with APM, Oracle Fusion Application’s development methodology.

The book, by Shane Warden and James Shore, is a great introduction to agile development methodologies by covering both XP and scrum. Practical examples are generally from XP projects because that is where the authors have the greatest experience. The authors identify a broad set of practices that would be considered as characteristics of agile development methodologies in way or another. Recognising that it is very rare in most organisations to be able to follow an agile methodology completely as prescribed alternatives are mentioned, but not in every case. Shane and James are also very clear that many of these practices are often taking place at the same time in a software project rather than in a sequential waterfall methodology. However, categorising practices by what sort of activity and the nature of the activity give a very useful matrix for teams to analyse how agile their own practices are and perhaps identify areas where realistic improvements can be made. Just being able to have a label or term for a specific practice makes discussing within a group easier.

Download poster from James Shore

I see the collection of practices being grouped by phases (planning, analysis, design & coding, testing, deployment) and verbs (thinking, collaborating, releasing, planning, developing). For example, when team members are working on implementing a specific feature that kind of collaboration is ‘design & coding collaborating’ and the section in the book covers some pair programming techniques. In fact, this particular section addresses the misconception that pair programming is a fulltime ‘paired for life’ regime. It is a useful tool that can be used for a few hours a day to make some significant progress, reduce interruptions, and spread the knowledge of how and why parts of the system being developed work.

Other useful techniques peppered through the book include the Agility Self Assessment and the many skill development routines, which the authors called ‘etudes’. These are short exercises that may help in getting the feel for a more agile approach. When reading the chapters you might be thinking we don’t have the development experience to let team members do organic, incremental architecture design, or implement thorough automated testing. I wonder how many people never complete the book because they do not believe they can carry out these changes and deliver software in a timely fashion. It’s not until towards the end of the book that the authors address the reality of the mixed capabilities of the team. If this was at the beginning it might give the readers more staying power. The book does have some helpful advice on working with and around the politics, the mixture in experience levels, and heavy weight project management within your organisation. It has to be read in it’s entirety though and does make for an excellent reference book to dip in and out of.

This article has been edited since it was first published.

Your ScrumMaster is a project manager in disguise

In 6 attributes of a good ScrumMaster Mike Cohn repeats the common line that the ScrumMaster role does not always require a full-time, eight-hour-a-day commitment. Often the ‘orchestra conductor’ role of ScrumMaster is an unofficial one within your organisation even though it clearly has well defined functions and responsibilities. So many people do ask the question Is a ScrumMaster a full time position? As Boris points out, it is, and he explains why it is a 100% fulltime job.

The ScrumMaster has internal and external responsibilities. Even if the team is well disciplined with following the process, and they address most of their own impediments there is still the challenge of being a gatekeeper between the management and the team. This is being recognised in many organisations now and you can even see ScrumMaster as a recruitment position. It’s interesting to note that many of these positions have Project Manager / ScrumMaster as the title.

What does a Project Manager do that a ScrumMaster does not (or vice versa)? A project manager is the person who has the overall responsibility for the successful planning and execution of a project. This title is used in the construction industry, architecture, information technology and many different occupations that are based on production of a product or service. While strictly speaking, the team, rather than the ScrumMaster has responsibility for the success of the project, a ScrumMaster does assume responsibility for the team’s adoption of Scrum and practice of it. A ScrumMaster takes on this responsibility without assuming any of the power that might be useful in achieving in it.

To boil it all down to it’s essence, a ScrumMaster is a Project Manager who has realised that they don’t really have the power to successfully deliver a project, and has adopted a framework to take advantage of that humbling position.

Priorities in agile software development

After discussions with friends, family and work colleagues over the past few months it became apparent that we all have a different idea on what priorities are and how do we identify priorities. Here are my thoughts on the matter.
Why prioritise?
It’s very dangerous to ask staff and customers what they want to see in the next release. The result is a mixed wish list of the most amazing things. By the time you’re ready to start development, you’ve got enough ideas for improvement to occupy 500 programmers for a few decades. A long list of features is a good place to start, but it needs to be prioritised.
Unfortunately, all you have is three, and we wanted to be shipping within 6 months, so there has to be some prioritisation. Time is an important resource, and we have a limited amount of it. With software, one does not have the luxury of a long development period to bring a product, or a new release of an existing product, to the market. Potential new customers will not be interested in a product that does not improve on a regular basis. Someone else may do it quicker. Your customers may migrate to a different solution that has the feature(s) they are looking for.

Capacity must be influencing our priorities. Because capacity is time based, our priorities are time based. Too many software development teams suffer from ‘inflation of time’; that is to say, they devalue future time by using it to solve present problems. The problems may not be the most important ones to solve today. Of course, the time spent on one thing means that some other activity remains undone. Each time we put off a portion of our work to do at a later date, becaue we haven’t time to do it today, we are devaluing future time in the sense that we now have less of it.

No one can juggle tasks indefinitely. Hard decisions have to be made about what matters.There can be a tendency for people to avoid the hard decisions and use capacity, or estimation of effort to set the priorities. For example, if the risk management feature takes more effort to implement we’ll go with the loan book profitability feature instead. While capacity is effective in determining what to do with activities of the same priority, it is not the only influencing factor in establishing a prioritised product backlog. There may be features that are must haves for the next release. They may be expensive to implement, but without them market share may not grow. This is where market research is really important. The product owner must be able to say: “To get the risk management feature we can sacrifice the loan book profitability feature because risk management addresses a need for a broader range of potential high value customers.” The product owner must also have the courage of their convictions and vision, based on their research and understanding of the market. Just because something is difficult does not mean it is not worth doing.

Prioritisation pitfalls

Sometimes certain features or activities can appear to be important and necessary in the next release. Here are some prioritisation pitfalls. If you find yourself condsidering this sort of features in your next release, spending some more time on research, verifying the importance.

Single customer requirements

It is generally cheaper to get new business from existing customers than it is to get new customers. Having customers can cause it’s own headaches, particularly if your sales person has sold the customer a product you don’t sell. This happens a lot more than it should, and opens the door to legal hassles that are just not worth the effort. Even when this doesn’t happen, there can often be enhancements suggested by your customers. Many of these will make sense, others may be bespoke features that no one else is interested in. Building features into your software based on single customer requirements implies that you are actually building consultant-ware, not shrinkwrap software. Shrinkwrap software is better than consultant-ware. That’s because shrinkwrap has no marginal costs for each additional customer, so you can essentially sell the same thing over and over again and make a lot more profit. Not only that, but you can lower the price, because you can spread your development costs out over a lot more customers, and lowering the price gets you more customers because more people will suddenly find your now-cheaper software worthwhile, and life is good and all is sweet. If you have customers that are requesting unique features not no other customer is requesting, then perhaps the real priority feature is a plug-in architecture, rather than the business feature.

Perceived inevitable requirements

Good software developers often think in the abstract so that the real implementations are more reusable in concrete scenarios. However, just because something is the next logical thing to do, does not mean it is the most important thing to do next. For example, a system may have a notification module with SMTP and SMS interfaces. A logical next step would be a XMPP interface for instant messaging. Such a feature may be interesting for the developer to work on, and may even give the marketing department something cool and trendy to draw attention to, but is it a deal clinching feature? Are more customers looking for this feature than some other feature, such as not notifying people who are on leave, but they’re deputies instead?

Prioritise interface that the user sees

A prioritised list, reflecting the capacity of the team, and what the business value of the new features are makes for a more sustainable development effort.There is one category of features that software developers may subconsciously discount. I’m referring to what the end user interacts with as a tool to for their job. The interface with your software may not be the GUI, but also a web service or a device. These deserve our attention because they increase the awareness of the value of what we can do with technology. Nobody sees a shared library or a driver, and no one cares about them, unless they’re broken. Yet that’s where software developers can tend to focus much of their time and resources. Doesn’t this contradict an earlier point about building a plug-in architecture? No. The motivation, in that case, to build something that the user does not see, is to provide a sustainable and cost effective solution so that the customer gets what they want (a business feature) without you having to provide it or maintain it.

A prioritised list, reflecting the capacity of the team, and what the business value of the new features are makes for a more sustainable (if no one pays for it, who pays the team) development effort down through the years.

Offshoring / Outsourcing with scrum

Clearly the use of scrum with distributed teams is something a lot of people are talking about right now. After last months article on scrum and offshoring, focusing mostly on communication challenges, I have noticed a number of blog postings on the subject. David Myers (a consultant at London based Charteris), in his article on Scrum and Outsourcing, goes into great detail about the challenges with distributed teams. For me, the key points are that basic agile practices of communication, meaningful documentation and continuous integration removes some of the hurdles. However, the manner that the standards / approaches applied have to suit the team.

I’ll leave the last word to David…

For me the most important consideration when employing Scrum with offshore resources is that it should not be employed without modifying and/or tuning some of the practices to be more suited to working with geographically split teams. This tweaking (or lack thereof) can have a fundamental effect on the end result.

Does “scrum” work in offshoring?

A question posed a few months back on stackoverflow on scrum and offshoring got a number of mixed responses. Many state that scrum does not work with remote teams. There may be a number of factors to scrum not working, which has very little to do with scrum in the first place. Some teams are not suitable to scrum, or rather, the individuals on the team are not suitable. Scrum requires a change in mindset, to be proactive, not be willing to fail, and be willing to be honest.

The time difference does appear to be the biggest obstacle. Many of the other issues, such as cultural differences, can be resolved, or at least mitigated, with direct communication. Direct communication is hampered when remote teams work in different time zones.

Flexibility is required from the team members in all locations. It may suit some members of the team to start early and leave early so that their working hours overlap with some of the others. This has to be sustainable. The team members that come in early should not be the ones who regularly leave late. If this occurs, there is a problem with resource bottlenecking. What would happen to the team when this member goes on holidays? A meeting that involves the whole team is often not required if the team members take the responsibility to communicate to each other. I have found instant messaging to be quite useful in this regard. When having a discussion with some team members in a chat room, the messages can be saved and posted to a wiki or emailed to the rest of the team. This also helps to clear up confusion over what was said during a telephone conversation.

Note that I only refer to one team. Referring to a group of team members by their location may reinforce the differences between the groups. For example, rather that referring to team members as the ‘San Jose Team’ or the ‘Palo Alto Team’, try ‘The team members in San Jose’ or ‘The team members in Palo Alto’. This suitable change emphasises that the team is one unit, just distributed.