Feb 102013
 

My instincts tell me to be sceptical about having a defined SDLC (Software Development Life Cycle) – it feels like an old paradigm that is fundamentally waterfall in approach. However, it’s entirely understandable for organisations to ask questions like “This Scrum/Agile thing is working fine for engineering but is that as far as it goes? How do we decide what to build? What do we report to the board? Where do non-IT teams fit in? How does the whole process work, from idea to live product?”

There’s some great books and an active community focused on these questions, but much as I would like everybody to embrace the complexity and nuances of Product Ownership, Lean Startup, DevOps, System Thinking – and more – most people don’t have the appetite or enthusiasm to study and digest all of that. That doesn’t make their questions any less valid. In fact, the breadth and complexity of this field is crying out to be brought together in one coherent picture of a system that turns ideas into high-quality production software, adding business value and delighting customers.

I like a challenge (!) so have put together a software product life cycle with five stages. The stages can be mapped to other models, but I believe are more naturally named here and more clearly aligned to Agile/Lean principles:

  • Imagine. Ideas are the lifeblood of business and product development. At this stage we need to pull contributions from all internal and external stakeholders, engendering a culture where anyone feels like they can contribute and get recognition. Ideas beget ideas, and volume is a virtue.
  • Assess. The challenge with ideas is that while each might at first seem valuable, it will turn out at some future point that the majority are not. We need to find out which are worthwhile as quickly and cheaply as possible – to “fail fast” with the majority so we can find and focus on the real winners.
  • Envision. Once we have found an idea that is worth pursuing, we need to clearly set out the problem or opportunity we want to tackle, and how our idea meets that challenge. It’s also valuable to talk about scope, stakeholders, technical architecture, potential problems, team make-up, and approximate size and duration of effort.
  • Deliver. Agile and Scrum focus on delivery, because that’s where software projects have been notorious for failing. Technology, quality, and engineering practices come to the fore here but we must not lose sight of why we are building the software and for who.
  • Operate. Approaches like Lean Startup and DevOps have shown us that building software, and even delivering it, shouldn’t be the end of the process but only the beginning. Once software is in customers’ hands we need to support them, measure performance and usage, get feedback, and push what we learn back into the Imagine stage.

This cycle fits for small features – in which case it may last only hours and probably have no outputs other than those integral to delivery. It fits best, however, for substantial new product or feature development – in which case it may span several months. (Initiatives likely to be longer than several months should be split.)

Note that meeting the purpose of each stage is much more important than the amount of time spent or the artefacts produced, and the cycle can (and should) be abandoned at any point if a change to the business environment or new insight means the idea is no longer of value.

Six core values run through the cycle, reflecting the Agile/Lean mindset while retaining a practical slant towards the needs of the modern enterprise:

  • Business Value. First and foremost, businesses need to make money to survive. Whatever approach we ally ourselves to, we should be united in a common goal of helping our organisations succeed.
  • Customer Focus. All businesses have customers, and we need to focus on them through the whole life cycle to successfully deliver products that will delight them.
  • Measure and Assess.We should be generating and analysing metrics continuously so new ideas that won’t work are weeded out fast, new technology is evaluated and leveraged, and production software tuned and enhanced – based on real data, not guesses or the whims of the powerful.
  • Collaborate and Communicate. In an enterprise setting, the development of revenue-generating software tends to involve many functionally-based stakeholders from finance, sales, product, user experience, marketing, IT and so on. The best results come from being transparent and accessible to all stakeholders, and where appropriate working with them as team members.
  • Excellence in Technology. Being great at software engineering isn’t a nice-to-have, it’s fundamental to an organisation’s ability to prototype quickly, deliver often, and make changes safely when new opportunities (or threats) arise.
  • Governance. Executives need to “see into” the process, most often at a high-level but with supporting detail when needed, so they can make informed decisions and communicate clearly to investors.

In my next post I will show how the stages and values map together, and the activities that support them. I’ll also highlight suitable tools, techniques and outputs.

Nov 242012
 

Retrospectives are no less important for distributed teams than co-located ones, but there are additional challenges that have to be overcome to make them effective. In this post I’ll share a few of the things I have learned.

Timing

What’s the right schedule for retrospectives with a distributed team? With co-located teams, I like to end sprints on Fridays, and have a retrospective at the very end of the sprint – not wrapped up with the planning for next one. This brings psychological “closure” to the sprint, giving the team an opportunity to get everything out in the open so they can relax at the weekend, and come fresh to the planning session for the next one. With distributed teams in different time-zones this might not be feasible, but I recommend getting as close to it as possible.

Well managed retrospectives with co-located teams can run for a couple of hours or more without losing their way – or the concentration of the team! Much more intense concentration is needed to engage in a long conference or video call, and I’ve found that when the hour mark is passed the meeting becomes less and less productive. So, time-box the retrospective to ninety minutes, but craft an agenda that’s doable in sixty.

Culture

Cultural differences come to the fore in retrospectives. In particular, different norms around hierarchy, openness and directness can but a big damper on the whole effort. You can’t change someone’s cultural background but you can do a lot to explain the purpose of the retrospective, and ask them to step outside their comfort zone for a little while so the meeting can achieve its goals.

Use the Retrospective Prime Directive as a starting point, and give examples of the kind of feedback you expect. Use activities which allow team members to feedback anonymously, when you think that might expose facts and opinions that would otherwise stay hidden. If all else fails, talk to team members individually before the retrospective, help them understand the value of giving their input to the whole team, and to think of ways to communicate unambiguously that are also comfortable for them personally.

Technology

Thankfully, we have come a long way from telephone conference calls in the past few years! Retrospectives that only use audio tend to be tedious in the extreme, and although video calling is better it remains a far cry from the rich interaction that comes quite painlessly when the team is in a room together.

There is plenty of new technology which helps us rediscover that ease and richness of collaboration. CorkboardMe is a simple and highly responsive virtual board – of infinite dimensions – that the team can add virtual post-it notes simultaneously. It works really well for visual activities like Mad/Sad/Glad, as shown below. It is limited to post-it notes of different colours and sizes – there’s no freehand drawing – so plan in advance how you will work within that.

Scribblar.com is similar, but a free-form whiteboard. It’s flexibility means a lot more hands-on facilitation is needed, but used judiciously it can solve some difficult remote collaboration problems.

.

And finally…

The retrospective is an absolutely crucial part of Agile and Scrum¬† – the driver of improvements that allows us to focus on execution during the sprint, safe in the knowledge that everyone will get an genuine opportunity to speak their minds at the end. No matter how dysfunctional a project may be, a working retrospective brings it all out into the open, and drives the team to take specific actions for the greater good of the project and the team. Wherever a team happens to be located, it’s a part of the process that we simply can’t do without.

Nov 062012
 

I passed the Scrum Alliance’s (relatively) new CSP exam last week. Before the switch to a 3-hour 150-question multiple choice format, the qualification was assessed by submission of a written case-study. There was a substantial backlog of papers to grade, which is not surprising as that job, I am told, fell to unpaid Alliance volunteers!

The exam was unlike any I had taken before, so made the whole process of study and assessment an interesting experience which I think is worthy of covering here. What made it so unusual? First, the sheer volume of questions – 150! The CSP exam handbook (PDF) classifies the content into 65 “tasks” in 7 domains, which goes some way to explaining why the questions have to go on… and on… and on. Secondly, some questions are “fluffy” – there’s room for interpretation and shades of correctness requiring you to choose the option which is “most” or “best”. There are sample questions in the exam handbook and a $20, 35-question practice test which illustrate this.

If you have arrived at this blog post from a search engine, you probably want some tips on the exam. I’m happy to give some pointers, but it’s a tough exam so don’t expect that reading a few tips will make it easy to pass!

1. Study

There’s no way around it, this is an exam you have to prepare for with good old fashioned cramming from books. And passive reading isn’t going to cut it, you really have to understand. For me, that means sloooooow reading with plenty of time for reflection and wherever possible, application. There’s nothing like real-world use to take lessons to heart.

The exam handbook has a useful reading list. The stand-out book for me is Scrum Alliance Chairman Mike Cohn’s Succeeding with Agile: Software Development Using Scrum. This has a fantastic scope and gives a good grounding in Scrum beyond the basic framework. Read it, then try as much of it as you can in practice. Then read it again. Then read some of the other books.

2. Read related content

I’ve always found that “reading around a subject” – studying content that’s related but not integral – is very effective. Knowing more than you strictly need to somehow makes it a lot easier to understand what you must. It also provides some mental recuperation without completely going off-piste with the latest paranormal romance (which is, by the way, a genre of fiction that really doesn’t need to exist).

Scrum is about people, technology, management, innovation and much more – so there’s plenty of books you can use to “read around”. On my reading list I had Dan Ariely’s Predictably Irrational and David Anderson’s Kanban, as well as a lot of technical tomes. None of those are about Scrum, but do a great deal to put it into context.

Another great way to learn around is to take part in conferences, meet-ups, and other groups. By sharing experiences you can put yourself in the shoes of other practitioners, and gain an appreciation of situations that you have never seen first-hand.

3. It’s Scrum, Jim, but not as we know it

CSP is a Scrum qualification, but the goes well beyond the mechanics of Scrum – a fact well-illustrated by the content outline in the handbook. Knowing the Scrum Guide backwards is the foundation for CSM and Scrum.org’s PSM I, but won’t cut it for CSP.

A good appreciation of Agile as a generic approach and related technical practices are pretty crucial – you need to have really internalised the Agile mindset to quickly (almost instinctively) assess the right approach in different situations.

4. Put it into practice (but don’t get tunnel vision)

I can’t imagine someone passing the exam without getting into the sticky business of doing Scrum/Agile in the real world. In fact, 2,000 hours of Scrum-related work in the past two years are an eligibility requirement. Working as a ScrumMaster is the most obvious position, but any Scrum role (i.e. developer or Product Owner) could in theory provide the right exposure and opportunities.

Be careful to use your experience but not be constrained by it. CSP takes a broad view of the Scrum world and your experiences are likely to be narrower, and sometimes in conflict, with what’s best in a broad range of circumstances.

5. General multiple-choice exam tips

The common, time-honoured, advice for multiple choice tests is worth bearing in mind. There’s some good tips in the exam handbook, but the ones I find most useful are:

  • Use a process of elimination. If you aren’t confident of the answer but can eliminate two options, the odds are swung massively in your favour.
  • Take your time, but don’t agonise. Methodically work through the questions and when you have done all you can, move on. Racking your brains is more likely to lead to frustration than the right answer.
  • Take breaks. 150 questions is a lot. You can’t get up and stroll around, but you can close your eyes and relax a few moments at regular intervals. Getting a little breather can help maintain perspective.

Summary

I’ve taken a good few technical exams over the years, but the CSP is very different. You can’t simply cram and regurgitate facts to pass, which is refreshing – but challenging. I initially viewed the CSP with some scepticism but have come to appreciate that an automated exam which fairly assesses a complex, nuanced body of knowledge is quite an achievement, and it really means something to pass.