Paul Flewelling and Kirstin Donaldson hosted Episode 6 of The Board and they covered:
Episode 4 of The Board covered a range of topics:
We’ve put together a short video segment on one of the many learning games we play with people to help demonstrate the power of Scrum and Agile.
The Rope Game from Boost New Media on Vimeo.
We’ve also included the instructions for the game below.
If you are interested in using games to help your Scrum teams, we discuss the topic on our latest episode of The Board, The Board – Episode 6
—————–
Time:
3 to 7 minutes
Materials
How to play
PART 1
PART 2
Learning
This exercise demonstrates the power of a team’s ability to solve complex problems when they collaborate. It resonates with Scrum in that you encourage the team to be self organising to get the full benefit of their abilities.
If you try the game, please let us know how it went in the comments below!
Customer Collaboration over Contract Negotiation
This is the line that made me think Agile was crazy talk. Forever and as long as I can remember contracts were those magical force fields powered by legalese to help protect the customer from us and us from the customer. Admittedly contracts would never work. At best, an issue or change pops up and you go into renegotiation and a new agreement is established and signed and everyone is happy about the forcefield being back up and then BAM! It breaks again.
“What is more insane? Trying something new after what you’ve done doesn’t work or doing the same thing over and over again and expecting a different result?”
Of course when you go into business with someone you want a contract. You want to define the cost of work, budget, resources, etc. Those things are all relatively static. But when it comes to software, why would you sign off on features or specifics about a product that doesn’t exist yet? How can you be sure what you think you want, is really what you need?
Unless you or your customer comes with a crystal ball or a supped up custom DeLorean, it’s unlikely either of you will know for sure what will end up being the most important features in the product. As the project evolves and work is continuously prioritized, those truths reveal themselves. This is even without considering the likelihood that the requirements will need to change for the customer to keep a competitive advantage.
So if our perception of the product will change as we get to know it better through working with it, who better to ensure the quality of the product than the customer? No one. Having the customer with you every step of the way, available for quick questions and clarifications ensures that there is no misunderstanding when the product is delivered. A living and interactive “contract”… some people call it a relationship.
Like any relationship it requires a commitment of time from the customer. Though this may seem like a big ask; the bigger question is this: How important is this product to them?
In Scrum this means that in addition to being readily available, the customer (or Product Owner – PO) also creates User Stories to define the features they need. They then prioritise these stories in order of business value. This small but important act of organization forces the PO to separate the work they need from the ones they want and thus helps the team to continuously deliver a product of the highest business value.
As the project progresses, User Stories the PO thought they needed “without a doubt” in the beginning of the project can often find themselves at the bottom of the pile, with little likelihood of ever getting picked up. As the PO works with the team and prioritizes the solutions they need, they learn more about what those solutions actually are, versus what they expected them to be. Often the team will provide simpler and more elegant solutions than original thought necessary.
Thus the act of creation is also an act of learning, for everyone involved. Understanding this and embracing it as the norm has created some amazing results here at Boost. Not just in terms of products, but also in terms of people’s outlook on future projects.
Getting a client to become a Product Owner can be difficult. Do any of you have any strategies for bringing them over? Or even just some favorite stories about the changes you see people make as they stop being a passive client and become and active PO?
We’ve run several Certified Scrum Master (CSM) courses at our office in Wellington in the past year and we’re thinking of running another in the first quarter of 2013. If you or your colleagues are interested in attending a CSM course in the second half April of this year, we’d like to hear from you.
Our trainer is Kane Mar, Kane has been developing, coaching and leading software projects for the last 20 years. Mar became one of the first 30 Certified Scrum Trainers in 2006, and one of the very first Certified Scrum Coaches in 2007. He has trained and coached software teams throughout North America and Northern Europe. Mar’s profile at the Scrum Alliance can be found here: http://www.scrumalliance.org/profiles/11-kane-mar.
All of us here at Boost have undergone CSM training with Kane and we highly recommend his fun and engaging approach.
To register your interest please email us: [email protected]
A Scrum developer team is made up of 5-9 people. But what if the Development Team is only 2? Is Scrum still the right choice?
I’ve recently shadowed a project where there was 1 developer and 1 designer. We were asked to recreate a website that had taken a year to build with another organisation. We recommended the client start from scratch. The catch was that we only had a budget that would cover us for just five weeks.
With the short timeframe and an existing product (albeit a disliked one) to compare against, Scrum certainly seemed like the right choice. It would allow us to deliver the highest value features to the client first, and quickly. The trick was how to adjust Scrum for 2 workers and avoid becoming a Scrum, but.
The team agreed that one week sprints with the PO coming in three times a week (Monday, Wednesday, Friday) for the morning standups would be a good place to start.
All in all Scrum worked well for us in this situation but with the time pressure and the small team there were a number of issues we had to address.
Story Sizing – Our developers are used to two week sprints or more, plus they usually have a number of other developers to help size user stories. For these two reasons they sized the one story they had for the first sprint too small and failed to deliver. The good news was that they weren’t far off and on the day of the first review (in which we couldn’t show anything) they had closed that story.
The team quickly learned from this and took the time we had set aside for the review to break down the user stories in the backlog into more manageable chunks. The retro went well and all of the bumps of the first sprint were addressed. Going forward, the team’s productivity increased with each sprint and at the end of five weeks they delivered a product the client could use in production and that addressed their most pressing requirements.
Team Work - With only one developer you do not get the benefit of multiple minds to find a solution. After all, the reason we work in teams is to benefit from more than one perspective. This was eventually addressed by opening up conversations between other developers in Boost to share solutions to “unknowns” in our team’s user stories.
How Close? – After sprint 2, the developer and the designer decided that they should work side by side to optimize communication. This definitely improved their performance. This need was recognised primarily due to the time frame in this project, in addition to increasing performance it also lead to better sizing of the stories going forward.
Meetings - This wasn’t a problem, just an observation. I was coming from a larger project (6 developers/2 week sprints/indefinite time) to this quick one and it made me feel like the daily stand-ups, reviews and retros went too quickly. The rapid speed in which choices were being made and actions executed left me worried that maybe we going too fast and not discussing enough. Of course the team took just the amount of time they needed with only two people and such a short timeframe to work in. It wasn’t long until I understood this and was able to enjoy the rapid pace.
In the end, Scrum worked great on the two person team. It was particularly important in respect to the constraints on time/budget as it forced our Product Owner to organize the backlog by the value of the features, for example always asking “so if you ran out of budget on this sprint, which story/feature could you not live without?”.
The quick sprints and retros allowed us to address issues with design and expectations as they appeared. The outcome was a site very different from the one originally built, but one that worked exactly the way the client needed it to.
It was a pleasure to be allowed to participate in this project as it really demonstrated to me the power of the Scrum methodology while working with motivated, open and creative people.
Last night I gave a presentation for Agile Welly on how Boost integrates UX and Design in to Scrum. Thanks to everyone who made the time to come along. For those who attended, and for those who couldn’t make it but are interested, you can now view the slides and the transcript on Slideshare.
We are still working behind the scenes on the Boost website and another sprint has come to an end, bringing with it a few more changes.
This week we’ve made one change to the Boost site, some changes to the site that houses our event’s bookings, and furthered our concept for the Boost design portfolio.
In our last post we talked about the Boost TV channel on livestream. We air a live show called The Board, where we talk about all things agile, every second Thursday.
Two shows have already been aired, so we thought it was time we made them easily accessible from the Boost website. You can now click through to the latest episode directly from the sidebar on the homepage, and if you are viewing it on a smartphone you’ll find it under our events information.
We are going to allow event attendees to book directly though our website in the near future, but until then Eventbrite handles it. Whilst they do a great job, we felt the jump from the Boost website to their page was a bit jarring due to the differences in colours used and the placeholder images that are displayed alongside each event.
We have replaced these images with Boost branded ones, and used similar fonts and colours to our own website, which in turn makes the transition feel a bit more seamless.
We had a story in the last sprint to come up with a concept for displaying Boost’s design work in an interesting way. There was no implementation necessary, so we showed a hand drawn concept at our sprint review. We can’t say too much about it now, as it’s still a work in progress, but our next step is to create a working prototype which we can show to the team here at Boost.
If they like what they see, we will design and build the portfolio, so expect an update on that soon.
We like talking Agile and we like talking Agile with other practitioners so we’ve started our own TV channel on Livestream, you can find us there live at 10.30am New Zealand time once a fortnight.
We also like talking Agile with other practitioners, so during each 20 minute episode we give viewers the opportunity to ask us questions or comment on our discussion via Livestream or twitter.
Tune in to The Board this Thursday 8th November, 10.30 am to hear us chat about all things Agile.
We’ve been continuing our work on the Boost website. Over the last few sprints we’ve shipped the following features:
We run a number of Agile events here at our Wellington office and we currently use Eventbrite to manage booking. Our upcoming events feature links to our Eventbrite page, however we found that Podio, which we use to manage attendees, had a less complex API to pull in information on upcoming event dates. We now have a story in our backlog to create a new page that will allow attendees to book via our website. We’ll move over to managing our events solely in Podio as the API allows us far more flexibility to integrate signups with the administration of attendees.
We had previously organised our services section with quite generic headings and had featured client names as headings, we’ve now tweaked the content and layout so that the headings are more specific and the projects we’ve featured support the types of services we offer. For example, previously we’d named the top section ‘Web’ and featured projects by client with distinct boxes around each featured client/project underneath the heading. We’ve now revised the title to read ‘Website application development’, which more accurately describes what we do. We then redesigned the content underneath so that we feature types of web application development as sub headings and then detail specific projects demonstrating our capabilities in that area. We think this gives a clearer idea of where our expertise lies.
Keep watching this space and our homepage for further developments.
