Category Archives: Scrum

On Top of Your Game

On Top Of Your Game

Sharpen The Saw

I love the idea of being able to take some philosophical ideal and somehow apply it to my world. If it can be used to help solve real issues, remove blockers and/or present opportunities for continual improvement, then that must be a good thing. Most agile practitioners or enthusiasts have heard of the concept of Kaizen. It’s a principle from Japanese philosophy that says something like, small changes made daily add up to life changing experiences. The corollaries are many with some being stated by famous personalities over the years. One of my favourites is by Albert Einstein when he postulated; “compounding is the greatest mathematical discovery of all time”.

Read More

Of course he’s right. Small changes really do add up, and they really can bring large benefits over time. This whole concept got me thinking, about how I might try to apply the same thing to a typical agile delivery model. What improvements might I look for that could be applied daily and that would continually improve the application delivery lifecycle? Where could I find small adjustments that are easy to understand, even easier to implement and yet  still yield measurable results over time?

There are so many elements to consider. Some are process orientated, some related to tools and yet others that were clearly about people? When I started to get into it, I realised that there wasn’t a simple answer and that like Kaizen itself, I would have to take things in small, discrete quantities, each addressing the various elements of the whole. Delivering working software would be essential to the whole thing obviously, but what are the dependencies and how can they be manipulated for the better?

In the agile delivery world, understandably there are many, many tools and processes across the full stack of any given platform, be they open source or proprietary. I decided that one way forward might be to go back to the agile manifesto and look at the 4 core values. In other words, to examine: individuals and interactions over processes and tools; working software over comprehensive documentation; customer collaboration over contract negotiation and responding to change over following a plan.

Would it be relatively straightforward to address each one with a Kaizen mind set? I wasn’t sure, but I thought that I should try to work through it by a process of inductive reasoning. My conclusions wouldn’t be guaranteed, but perhaps more common sense-based. There wouldn’t be a step-by-step guide to agile delivery heaven, but if I realised that if I could manage to change just one, small thing daily, then perhaps I might find myself on the road to agile, cumulative righteousness.

Steven Covey phrases it well when he talks about “sharpening the saw”, [1] . In his book he asks us to apply the habit to ourselves. In doing so, I think that we cannot but help apply it to our lives and our work. To keep the saw sharp is to be at the top of your game, to deliver well using the tools at hand and a winning mind set. As the New Zealand All Blacks say, “ritualise to actualise” [2].

In this blog, I will address the agile manifesto with a ‘Kaizen’/’sharpen the saw’, mind set. I will look at tools and processes, and the importance of working software. I will examine why people and interactions are at the heart of every successful delivery model and why being able to adapt with minimal fuss is still important for businesses today.

Kaizen and the Agile Manifesto

In this section I’ll aim to develop the concepts of ‘Kaizen’ and ‘sharpening the saw’ and logically extend them to the agile manifesto.

Value 1 – Individuals and interactions over Processes and Tools
In my mind and in practice, individuals and interactions are interweaved. Therefore to ‘sharpen the saw’, we must look to the core of each to properly understand what exactly can be improved. We should work to build upon the following each and every day: trust (individuals and teams); value (your relationships); authenticity (be genuine in your dealings); flexibility (to maintain a healthy work life balance); development (encouraged, recognised and rewarded) and integrity (doing the stuff you said you would do).

Processes and Tools are extremely important but they alone are pretty useless without people and interactions to wield them.

Value 2 – Working Software over Comprehensive Documentation
Ensure that the spirit of the team captures the idea of delighting customers each iteration by continually delivering working software and something of value, no matter how small. It’s hard to over-estimate the meaning of this and in my mind extends back to the individuals and interactions part of Value 1. By delivering working code, as an agile team, we accomplish many valuable achievements. We increase team morale, we build trust with our customers and ourselves. We keep our business alive by shipping products that earn revenue. Delivering working software should be a value that is at the heart of every team and we would do well do remind ourselves of that on a regular basis. Working code, means revenue!

Comprehensive documentation can be extremely important, but if we have no working software, it’s pretty pointless. Documentation should definitely not be forgotten and agile is certainly not an excuse to develop code without it.

Value 3 – Customer Collaboration over Contract Negotiation
Much pain has come from awkward or badly negotiated contracts and much of this could have been ameliorated by focusing at least equally on effective customer collaboration. Build and maintain good relationships with customers is at least half the battle of delivering a great product. Like Value 2, Value 3 also harks back to Value 1, individuals and interactions. It’s much easier and productive to collaborate than to negotiate.

Value 4 – Responding to Change over Following a Plan
Plan for change is the best way to think about this. Within teams it is a really good idea to help them understand that adapting to change quickly and with minimal fuss is not only great for efficient delivery, but also for team morale. A happy team is a productive team, is a responsive team.

I am also a firm believer in the tenet that an organisation will eventually or inevitable move into a phase of decline, unless there is a concerted effort to prepare for change; EVEN when sitting on top of a current and very successful peak.

Try Ten Plus One Top Tips To Transform your Tech Team

Ten Plus One

Trundling (I can’t surf) over the net I’ve noticed that there’s one thing that continuously and conspicuously bubbles-up on most blogs at some point in their lifetime. Yes it’s the infamous top-N list, where N happens to be any positive integer from 1 to about 200 (and counting). The most common list seems to be the top-ten; I suppose it’s the most intuitive and it’s probably the most likely to be remembered considering most of us have ten readily accessible digits (yes, five on each hand), to help us count and assist with the retention of basic information.

I’m not against the top-ten list, that would be ‘intergerist’ or even ‘top-tenist’, I actually support the concept, but I do think that when creating a list people should try to be a little more inventive. A lot of top-tens are copies of other websites and present little or no new information. They should at least give us some entertainment value, a little bang for our buck so to speak. Whilst this can still be useful it has (for me) less of an appeal, it shows a decided lack of imagination. Consequently when thinking about how to compile my top-ten, I decided to take a different approach. First, let’s move away from the idea of having ten, a top-eleven I thought, well that would be like Spinal Tap going “one louder”, [] on their somewhat unique Marshall amplifier. OK, I’m a little tongue-in-cheek here, it’s a simple change and is evidently not going to revolutionise the top-ten list. No we require something a little cleverer than that. So, I’ve also combined my list with a little bit of word play, that is both interesting and relevant.

Since this blog is supposed to be at the very least tech-related, it makes sense to push a top-eleven of something tech-related. Rather than provide a list of my favourite software tools, my least favourite Visual Studio foibles, or even the eleven coolest things on the web (how boring), I’ve combined a very popular and current list with what I think are relevant alliterative terms to create a list that is informative and entertaining, and hopefully a tad more memorable. That’s the idea after all, to inspire some learning.

So what’s my top-eleven list about then? Well, I’m going to take a standard list of important scrum master characteristics that you might find in any scrum master job description and then rather smartly, add some relevant applicable alliterative additions (see what I mean?). It wasn’t as facile as I first figured (sorry), but it is a bit more of an enjoyable read and some of it might actually stick in your head.

There are a few things that all scrum masters should try to implement, be it physical processes or philosophical constructs; the end result should be the same, i.e. an improved team spirit, a marked increase in efficiency, happy stakeholders and sleep-filled nights.

So without further ado, buckle-in and prepare for the rip-roaring, roller coaster ride that is my guide to the alliterative scrum master, top-eleven techniques for improving your team.

1. Servant Superior
To best serve your team try to adopt the position of the ‘servant superior’, you are their team lead, but you are also there to serve them, to remove impediments and to protect them from the outside influences of (meddling) stakeholders. Additionally, you should ensure that they have good access to all relevant artifacts during a sprint and provide daily updates of the burndown.

2. Communicative Councillor
May be obvious to some, but how many times have we seen lack of effective communication be the root cause of a misunderstanding of requirements, poor design, or ineffective testing? A ‘communicative councillor’ facilitates and encourages team communication, asks questions and provides sufficient feedback to ensure that everyone on the team knows the current state of play. Additionally, stakeholders have a degree of comfort when the are regularly kept informed.

3. Facilitative Friend
The ‘facilitative friend’ ensures that all scrum rituals take place at the correct times, within the correct timeboxes and with the correct people. The friend aspect emphasises that this is not necessarily a formal approach and everyone should feel comfortable and free to voice their own opinions without ridicule during the ritual meetings.

4. Assertive Almighty
Ultimately YOU as the scrum master must be able to ensure that Agile/Scrum concepts and principles are adhered to and you must be able to be a voice of reason and authority. In summary, you should be able to make the tough calls where appropriate and rule when necessary.

5. Situationally Savvy
You should be the first to notice differences and issues as they arise and elevate them to management. Always hearing things second-hand from the team is a sure sign that you don’t quite have your finger on the pulse of development. Ensure you are up-to-date by always having an open line of communication to the team and stakeholders.

6. Enthusiastic Entity
If you can’t be seen to be a high-energy leader with the ability to enthuse the team and get them motivated then don’t step up to the role of scrum master. It’s an agile role and you need to have an agile mind to deal with it.

7. Improving Intrapreneur
The intrapreneur is a person within a large corporation who takes direct responsibility for turning an idea into a profitable finished product through assertive risk-taking and innovation. You will do this and continually strive to grow your craft by learning new tools and techniques to manage yourself and the team.

8. Fight Fixer
Where there are disagreements the you must facilitate alternatives or different approaches so that conflicts are resolved quickly and effectively. Fix fights frighteningly fast!

9. Empowering Entrepreneur
An entrepreneur is a person who organizes, operates, and assumes the risk for a business venture. This kind of spirit is great to have in a team and it is up to you as scrum master to provide it.

10. Transparent Trustee
There is a trust between the team, the product owner and the scrum master and it is your job to bring disclosure and transparency to the business about development and grow business trust

11. Discussive Dude
Discussion is vital in a scrum team to ensure that everyone communicates what they are doing and to help them understand what others are doing. Additionally, if there are problems or impediments to progress, the scrum master needs to know as soon as possible, so make sure talk to your team frequently.

“I Am Not A Number, I Am A Free Man!”

No one likes to be numbered, categorised, graded, pigeonholed, ranked, classified or otherwise grouped into a systematic or a similalry defined logical set. We’re all individuals, right? Especially ‘us’ IT, techie-type individuals. We’re as unique as virtual grains of sand on a synthetic beach, washed up by the tides of cyber-space. We like to flaunt our egoistic personalities by adopting avatars, twitter handles and pen names etc., and we do it all in the name of individualistic pursuits or anonymity on the web. We like to distinguish and uniquely identify ourselves in the blogosphere, on forums, in games arenas and chat rooms or wherever it is we may electronically hang out and virtually socialise.

Well, I have news for you. According to this article we’re ALL going to be reduced to one of only three functional possibilities;

1. Consultants
2. Project managers
3. Developers

Now that the post is nearly one year old, is it still actually the case, or was it ever the case? Do we look around our offices and see only Consultants, Project Managers and Developers? And if we do, what then? Does that mean we’re more efficient or less creative? Now, call me boring but I’m all up for seeing and utilising the differences in people, and whilst we may broadly fit into categories I really don’t see the benefit of this mundane, over simplistic approach. After all do we not already relish in shoe-horning ourselves into rather pointless categories of height, size, race, religion etc.? And where exactly has that go us?

But this is not a philosophical debate, it’s practical one and I personally think that, in the IT industry there are more roles than just Consultants, Projects Managers and Developers. I mean if we’re going to be pedantic about it, what about the role of scrum master? Granted it’s a managerial-type role, but it’s mainly a servant leader role and usually not development orientated nor indeed does it necessarily involve managing projects as a whole. The fact that people have wide and varied skills is a good thing; it allows for, and is conducive towards creative thought processes, compromising attitudes and entrepreneurial ideas. If we were all the same or even broadly the same, what a dismally boring place we would have on our hands and how pathetically bland our work environments would be.

I could write more on this here, but it might appear as a rant and I am reminded this is a blog, so let’s consider and respond to the points raised on the website mentioned above.

Consultants first then…

1. Consultants

“Lets face it, all but the largest enterprises would prefer to not to have any IT professionals on staff, or at least as few as possible. It’s nothing personal against geeks, it’s just that IT pros are expensive and when IT departments get too big and centralized they tend to become experts at saying, NO. They block more progress than they enable.”

Now, I’m not sure what world this particular writer lives in, but generally in my world if you have spent a number of years learning, practicing and becoming well recognised as an industry professional in your arena, then I believe this entitles you to a decent salary. Furthermore, as a consultant myself I am used to making the effort to say “YES” to my clients. Obviously there are times when one simply cannot achieve what is being asked, usually within tight deadlines and/or cost estimates, and at those times it is best to say “NO”, but to suggest that IT departments generally say “NO” because they have ascertained and degree of power within an company is not a point-of-view that I would willingly go along with.

Next up and commenting on Project Managers, our writer suggests that…

2. Project managers

“Most of the IT workers that survive and remain as employees in traditional companies will be project managers. They will not be part of a centralized IT department, but will be spread out in the various business units and departments. They will be business analysts who will help the company leaders and managers make good technology decisions. They will gather business requirements and communicate with stakeholders about the technology solutions they need, and will also be proactive in looking for new technologies that can transform the business. These project managers will also serve as the company’s point of contact with technology vendors and consultants. If you look closely, you can already see a lot of current IT managers morphing in this direction.”

I may not disagree entirely here, but I think that it is a gross generalisation to say that employees who remain will become project mangers. Perhaps this may be true in very large scale organisations, but in small to medium-size companies there are simply not enough positions to justify everyone moving into a project management type role. Additionally, the idea of a project manager gathering business requirements etc. doesn’t quite ring true. Most projects that I have worked on have had a dedicated Business Intelligence Analyst to do that and the idea of a Project Manager communicating technical solutions to stakeholders is also rather flaky. Usually an architect or team of architects will design and present a technical solution to a client since many IT project managers do not have either an IT or technical background and are wholly incapable of operating in this area. The role of the Project Manager in a nutshell is the overall responsibility for the successful planning, execution, monitoring, control and closure of a project. They may perform other duties, but it is unlikely that this will be requirements capture, system design or any of the usual technical functions. There are of course exceptions and I have managed projects with a number of hats on, scrum master, developer, team lead, project manger etc., but on the whole this has not been my experience in the IT world.

Finally our writer considers the Developers, a bunch dear to my heart.

3. Developers

“By far, the area where the largest number of IT jobs is going to move is into developer, programmer, and coder jobs. While IT used to be about managing and deploying hardware and software, it’s going to increasingly be about web-based applications that will be expected to work smoothly, be self-evident, and require very little training or intervention from tech support. The other piece of the pie will be mobile applications both native apps and mobile web apps. As I wrote in my article, We’re entering the decade of the developer, the current changes in IT are shifting more of the power in the tech industry away from those who deploy and support apps to those who build them. This trend is already underway and it’s only going to accelerate over the next decade.”

OK, so there are some good points here I’ll admit, especially with the expansion of the mobile app world, but I think the writer falls short of fully understanding what a revolution this has actually been. In the past the developer role was a skilled role and usually took several years to master in any given language. Since IOS, Android and Windows CE were introduced, coupled with free IDEs, mobile emulators, on-line source code repositories etc. the ability for the average Joe to create a decent application has never been easier.

Coding is no longer the exclusive right of those who can afford the software tools and with many big software vendors offering ‘lite’ or free versions of their flagship software, it really has taken the development world by storm. The writer also fails to consider the other massive revolution which had definitely taken hold last year and which continues to boom; that of course is the ‘cloud’. Just put ‘estimated cloud growth’ into Google to see what the results are. It certainly doesn’t take a monkey with two heads to figure this one out. It’s massive.

So, lessons learned?

1. Forget about generalising people, not even in terms of functionality.
2. Focus on why people are different and how that can help your business.
3. Respect talent and give credit where it is due.
4. Give project managers a break they really can be useful (OK, a bit tongue-in-cheek).
5. Stick it out with longer blogs, they can be worth it.
6. Live long and prosper.

Scrum – Standup Speaking Order

Scrum Using Random Numbers

After taking up the mantle of scrum master in a distributed team, I quickly discovered a small issue with the daily standup. Normally, when a team is co-located a scrum master can use any one of a number of techniques to automatically decide the speaking order of the daily ritual; for example clockwise from the first person into the room, anti-clockwise from the person standing nearest the window; or randomly throwing a ball to a team member and have them do the same. There are many techniques similar to this, but none work effectively with geographically distributed teams who may be using a tool like Skype as the main method of communication. A few searches on the web soon highlighted that there is little advice for the organisation of distributed scrum teams and I didn’t find a satisfactory answer. I gave it some thought and hatched a plan of my own.

First, I thought it would be excellent if everyone in the team knew the order of the day before participating in the standup, and second, I did not want anyone, including myself dictating the order of the day after the standup had started. Scrum masters should act as servant masters and outside of facilitation, blocker removal etc. they should not really assume a role of superiority, nor should any of the other team members. It was clear that some kind of random process was required to generate numbers, something akin to rolling a die; but with 5 team members and 6 faces on a standard die, how was it to work?

It’s not rocket science and the answer I found was very simple. All dice do not necessarily have 6 sides and the ideally suited pentagonal trapezohedron has 10 sides. Why do I say ideally suited? Well with 5 team members each person can be allocated 2 numbers (sides) like so;

Team Member 1 = 1 & 6,
Team Member 2 = 2 & 7,
Team Member 3 = 3 & 8,
Team Member 4 = 4 & 9,
Team Member 5 = 5 & 10.

[Alphabetically by first name could be one way of deciding the order of team members.]

The Pentagonal Trapezohedron







Each morning (or at the specified standup time) one of the team will roll the virtual die, found here to decide the speaking order. Based on the example team above, if a 4 or a 9 is rolled first, then that team member speaks first and is awarded a single point. If a 2 or 7 is rolled next then that person speaks second and is awarded 2 points, and so on. At the end of the 5 rolls ( or one roll for each team member), the tally should look like the following;

Team Member 4 = 1,
Team Member 2 = 2,
Team Member 1 = 3,
Team Member 3 = 4,
Team Member 5 = 5.

Pretty simple really, and effective because on top of this a reward system is introduced whereby at the end of a given period, say 3 months an award is presented to the team member with the LEAST amount of points, i.e. the person who had to speak first, or as near to first, most of the time. Additionally my team have created a ‘Dice of Fortune’ chart which illustrates each person’s points position after the draw and adds a little excitement to the start of the day. This is how our chart looks after just over a month of play.






Rally – Application Lifecycle Management


Not so long ago I tweeted that my team had started to use Rally as the platform of choice for managing the software development side of our business. Having successfully completed a few sprints using Rally, I thought I would present a birdseye report on our ‘getting started with Rally’ experience and on how quickly we were able to adapt to the new environment.

If you are considering moving to an agile development approach or are looking for an alternative Application Lifecycle Management (ALM) platform then please do read on; there should be some useful information in this blog. Before describing my team’s experience with the platform, it is useful to introduce the Rally platform. Rally as a whole offers a lot more than an ALM application, the company’s products range from the free (locally installed) community edition to the full enterprise edition, offered on-premise or as a Software as a Service (SaaS)-based solution. Training can be provided on-site and a number of community resources are also available for use online. Wikipedia neatly summarises Rally in the following paragraph: “Rally Software, founded in 2002, offers SaaS-based Application Lifecycle Management (ALM) platform and products, Agile coaching services, courses through Agile University and online forums focused on Agile and Lean practices. Rally is based in Boulder, Colorado, with offices in Raleigh, North Carolina, and London, England.” [1]

Navigating to Rally’s URL a user is presented with a simple login page and when they log in for the first time they are asked to select from one of three roles; Contributor, Executive, Organiser. As team scrum master I selected the Organiser option and my team selected Contributor. Rally then provides a dashboard most suited to the role chosen. I spent a few days familiarising myself with the environment and entering the details from the team’s current backlog before introducing it to the team. The dashboard can be heavily customised and there is a wide range of widgets that can be added, rearranged and deleted to suit each user’s individual taste, see below.







My team is distributed, so it was essential that we could all log in, view and update the various screens within Rally as a team during our sprint planning meeting. The team found this to be extremely easy, navigating was clear and simple and adding items to the sprint backlog was also straightforward. We found that there was a little bit of confusion as to the best way to enter user stories since Rally offers a number of methods to do this, but once we had settled on a system this worked well. The task breakdown and estimation was also easily completed online during the sprint planning meeting and I found it very effective to have each member responsible for a task to enter the details for that task so that they were all involved in creating the sprint backlog.

During the sprint each team member has a time recording sheet where they enter the number of hours spent on their tasks, Rally is proactive about this and team members are also required to enter the number of hours they think remains for the same task. Initially this seems like an oversight, but not so. It is important since it is estimated time remaining and not time spent that is a more effective measure of how well the sprint is going.

At the end of the sprint Rally automatically calculates some basic sprint metrics and of course the burndown chart is available on the dashboard throughout the duration of the sprint. Additionally, Rally also offers the ability to create test plans and record application defects.

In summary, Rally provides an effective way to manage ALM and is ideally suited to agile scrum. Whilst training could prove useful, we found that anyone with an ounce of tech-savy should pick-up the techniques required for scrum-based software development. Rally is conducive to effective scrum rituals and enables quick production and clear visibility of scrum artifacts. It is certainly worth considering amongst the other platforms available.

Rally’s website here