I recently joined Boost after spending over a decade in the UK. Having worked within a traditional project management process over the last 5 years, I was very keen to learn about the benefits of Agile project management, specifically the benefits of Scrum and the comparison with my previous experience of web development projects.
What I found after a week of observation was that unlike my previous experience of web development projects, an ‘us and them’ (supplier v client) situation causing conflict and resentment is less likely to arise under Scrum. This is due to the scrum itself - both supplier and client are team members with clearly defined roles and responsibilities.
I was asked to observe a number of Scrum meetings in my first week; a stand-up, story sizing meeting and a retrospective.
The stand up
The stand up occurs daily and is a chance for the team to confirm what they are working on and to communicate progress from the previous day. I was immediately struck by the fact that each team member contributed to the stand up in the same way – developers are not asked what they are working on, they tell the team what they are working on and have the opportunity to identify any blockers to their progress. Although brief and straightforward this meeting immediately appears to be beneficial for a number of reasons.
the entire team knows exactly where in the sprint each person is
issues or blockers are raised early
progress is seen as it happens, stories are closed out each day throughout the sprint
Story sizing
Story sizing consists of all team members sitting around a table with a hand of sizing cards (numbered 1, 2, 3, 5, 8). A member of the team reads out a story, team members are then asked to ‘play’ a sizing card. The card indicates a measurement of effort that is not classified in time but by a proportional comparison. For example if the first story is sized as a 3 (or medium) then a story that is larger and will consist of more tasks may be sized as a 5 or 8. If a team member’s sizing differs dramatically from other team members the team member will then explain why they consider the story to be larger or smaller and after a discussion a consensus is reached. Sizing of stories informs the decision as to how many stories will be undertaken during the upcoming sprint.
The advantage of the entire team sitting down to size work as opposed to a more traditional method of having the developer who will undertake the work provide a time estimate is that each and every team member has a chance to input to the sizing of the story therefore the team takes responsibility for the timing of the story, as opposed to an individual. It is a transparent process that ensures the commitment of all team members to the delivery of each story.
The retrospective
The retrospective is a feedback meeting in which each team member is asked to focus on particular aspects of the previous sprint and to record both positive and negative feedback on these. The aims of a retrospective are for the team to communicate, review and improve on previous sprints. Retrospectives may be run in any number of ways in order to get the best out of the team.
During my observation of a retrospective I was immediately struck by the difference between this meeting and that of a traditional lessons learned meeting (held at the end of a traditionally managed project). The retrospective encouraged all team members to communicate openly. Contributions from team members are presented as statements, and are constructive rather than obstructive or defensive. The advantage of holding retrospectives regularly (at the end of each sprint) is that points are raised early and the project goes into a cycle of continuous improvement – as opposed to a traditional lessons learned meeting where any constructive conclusions are beneficial only to the next project the team works on.
My conclusions from my first week of observing Scrum in practice are very positive;
Developers are encouraged to fully participate in all meetings demonstrating work completed and inputting to decision points as required. As a direct result of their commitment to the project developers take a great degree of responsibility for project outcomes, they are very obviously accountable for tasks, while also having the benefit of the entire team’s support. All too often in non scrum projects the developer is asked to take responsibility for tasks in isolation and are therefore reluctant to commit to timescales and successful outcomes.
Clients are fully immersed and committed to the process and as such are very much a part of the team. Unlike projects I have worked on previously there is less expectation that the supplier will drive the project in isolation, instead the client is fully involved in all aspects of the project and always aware of exactly what work is taking place and when it will be delivered.
Processes are consistently reviewed for effectiveness and all team members input to the review process. There are opportunities for both positive and constructive feedback and actions are undertaken as a result. In comparison with the traditional ‘lessons learned’ aspect of a project this seems far more beneficial in terms of continuous improvement rather than undertaking process improvement at project conclusion.
Project tasks are broken down into explicit finite tasks and the acceptance criteria are clearly defined and agreed at the outset rather than development task estimates taking place at the outset of a project in isolation from other team members.
My overall impression in this early stage of exposure to Agile project management and Scrum is that Scrum builds a happier, closer team and minimises risk by ensuring frequent and open communication between all team members.
I’ve been coaching members of the Boost team in Agile off and on over the last few years, and by and large it has been useful and well received. But attending The Coaching Stance class run by the Agile Coaching Institute last week has really opened my eyes and made me reconsider what coaching means in the Agile context.
My own personal experience of coaching is firmly grounded in the sports world. The coach evaluates an area of performance, makes a teaching point or two, sets up a drill, evaluates whether the drill is correcting the weakness or fault, and then sets homework for the coming week.
So when I am with my golf coach it usually goes something like this:
I hit a few balls, some (not many) land on the fairway
Coach is videoing my swing
We review the swing together, and coach identifies an area for us to work on for that session
We do a drill or two, and see if that is impacting on my swing
I hit more balls then go home.
This is fairly typical and extremely useful. My golf has gone from “baboon attacks ball with stick” to “chimp attacks ball with more expensive stick” in only a year and 5 trips to the pro shop!
My approach to Agile coaching had, in many ways, mirrored this. I would talk with my client, identify an opportunity for improvement, and suggest something for them to try. Rinse and repeat. This has been effective on many occasions, but I’ve always wondered how I could do better.
The Agile Coaching Institute promotes co-active coaching, and this is what we were exposed to in our two day class. The class focussed on coaching, with the understanding that participants already had a deep understanding of Agile/Lean practices.
The class was the most effective training I have ever had. After two days I’d coached and been coached by over a dozen different people, and had moved my practice to a whole new level. I am excited by the possibilities it opens for myself, the Boost team and our clients. I’m not waiting until I get back to Wellington to put the training into practice: I’ve already been doing some coaching with the team back at work over the phone.
While it’s not easy or fair to try to distill the whole course into a paragraph or two, I’d like to reflect on the changes I’m already seeing in my practice. The biggest change is that I’m seeing coaching in a new light. I’m not there to problem-solve: my coaching client is whole, resourceful and creative, not someone who needs to be ‘fixed’ or ‘improved’. Instead, my role is to support the person I’m coaching to find their own solutions. This takes the pressure off me. I don’t need to know all the answers or figure out how to fix things: I can relax, and focus on what I’m hearing.
Cynthia, Lyssa and Michael provided a safe, supportive and honest space for us to learn and challenged us in many different ways. I was suprised by how quickly the class bonded. The coaching was at times intense ,and often suprisingly carthartic.
Thanks to everyone on the course. With so many talented Agile coaches, I know the Agile world is in good hands.
As an intern here at Boost I have had the privilege of working with a group of experienced and friendly developers. I have been here two weeks now and already feel settled in completely. One of the great things about working for Boost is that everybody is very approachable when you need to ask for help or when you need things to be elaborated. This has made the transition from university to industry easier than I initially expected.
Here at Boost we use the Agile software development methodology known as Scrum. So every day I have a stand up meeting with my scrum master (Jacob Creech) and product owner (Nathan Donaldson) where I go over what I have done, what I will be working on today, and discuss problems that I need to get out of my way. So far at Boost I have been working on bug fixes for our online usability testing tool IntuitionHQ, which is built in Ruby on Rails. Working in this way has helped me get my head around the large code base that I will gradually move towards developing features for.
The IntuitionHQ Scrum Board
Using Scrum means that I’m working in ‘sprints’, or two-week long development periods. Each bug in IntuitionHQ is written up as a user story. At the start of my first sprint I took part in a sprint planning meeting which included sizing the stories (assigning them points between 1 and 8 to indicate their complexity/the effort required to fix them) and then breaking the stories down into tasks. I had to indicate how many of the stories I could commit to in the two-week sprint, and how confident I was that I could complete them in that time frame.
As an intern I was not really sure how much I could complete, being new to Rails and working in the industry in general. But one of the cool things about Scrum is that at the end of each sprint you have a sprint retrospective. This is a chance to talk about how the sprint went, and what can be done to improve things. If I don’t complete all my stories in the first sprint, the next sprint will be adapted to deal with this, and so on and so forth. So in the case that I didn’t complete all my stories it will be known for the next sprint to take on less stories in relation to their size. Overall, this is about figuring out your ‘velocity’ – how many story points you can get done in a sprint.
For my first sprint I initially committed to seven stories. I ended up completing the stories early and brought in two more stories from the backlog. One of the fun things I have found about fixing bugs is it really stimulates the mind’s problem solving abilities. I developed most of my problem solving abilities while doing my Software Engineering degree at Victoria University. Although university is a great learning environment I have found that learning in a working environment has more merits. This is because you are working with a group of people towards a common goal so they are more likely to help you out and I find that social learning is the best way to learn. This differs from university as everybody in your papers are competing to get higher grades than you so they generally don’t feed you all the facts.
One of the cool things about coming out of university into a working environment is that once you get home from work it’s your time, not stressing-about-assignments time. I believe that the less stress you have weighing on your mind the more productive you can be. Not being stressed out has helped me to be more productive working here at Boost and has got me highly motivated and keen for my next sprint. To sum up my experiences so far I would say that working here has been awesome!
Here at Boost we’ve been pair programming for a while, and seeing benefits in the form of cohesion and knowledge sharing, as well as the quality of code we produce when working in pairs. As part of the adoption of this practice I set out to research how pair programming has been working for other teams and how it can be used to improve the team dynamics.
For those that are new to the concept of pair programming: at its core, it’s when two developers sit in front of the same computer and develop code together. One programmer acts as a driver and the other as the navigator. The driver controls the keyboard and mouse and is concerned with the concrete tasks of coding, while the navigator reviews the code and thinks about bigger picture issues.
It’s not for every team
As Obie Fernandez explains in his article “10 reasons pair programming is not for the masses”, in order for pairing to work the team has to consist of developers who are committed to their work, and who are sociable and able to interact with other team members. Otherwise problems will quickly arise when you are working in such close proximity with other team members.
Why it’s great
Few or no bugs: The first thing you will notice when pair programming is how few bugs are left in code produced by the pair. Pair programming is like a constant code review process, which is why typos or small details that a single programmer normally wouldn’t notice gets spotted almost instantly by the navigator, eliminating hours of debugging later on.
Code quality: The general quality of the code is also greatly increased. This is because while the driver is implementing the logic, the navigator is free both to spot errors and to think about the big picture and how it relates to the rest of the code.
Programmer productivity: When working alone it is very easy to get distracted by email, twitter, Facebook, and all the things going on within the office. When working in pairs, if you were to do any of those things it would waste the other person’s time, so pair programming is a constant reminder to focus on the work.
Knowledge transfer: In an environment where developers work alone, it can be hard to share knowledge because there often isn’t a time or place to do it. Pair programming involves constant discussion and flow of ideas on how to resolve a problem, and normally a pair can come up with many different solutions to a single problem. It’s also great in situations where you want to introduce a new team member, to get them up to speed very quickly with the development practices, coding style, git workflow and other practices the developers might use.
How to do it
When: Although some of the development companies promoting pair programming suggest using it 100% of the time, in my own experience the intense focus and concentration that happens with pair programming can be draining over a full day. I suggest you pick the tasks that will benefit from having a pair work on them, rather than applying pair programming to every task.
Workstation setup: We have been using just one display, keyboard and mouse with great success but I would definitely like to experiment with two keyboards and see how the interaction between developers works out.
Rotating pairs: One important aspect is to let developers constantly change pairs, on a daily or weekly basis. This has several benefits: it helps develop a bond between the team members; the team as a whole takes ownership of the code instead of individuals; and knowledge sharing is increased by working with developers with different levels of experience and backgrounds.
