By Ed Wong
In my previous article, I gave my impressions of my 2 days at Scrum Australia. As I mentioned, I ran a session which was an experience report of my time with Toll Global Logistics, helping out Risto Pearce, their Technical Development Manager, and his teams. Here is how it went.
Goal
Our goal for the session was:
To give an insight into to implementing and using Scrum in a corporate IT environment, and particularly the management perspective.
Format
We wanted to not just stand at a lectern with some slides, so we decided to go for a fireside chat format. You can see a prominent example of this, in the video below:
I played the role of Walt Mossberg/Kara Swisher, with Risto as the Bill Gates/Steve Jobs figure.
You can see the structure, and the questions that we prepared for the session in this Google Drive document. The Prezi that you can see at the top of this post, was used to add some visual interest, allowing me to dive in and show some photos to illustrate some of the points being made.
Selected highlights
We didn’t stick rigidly to the questions, as we wanted to keep things fairly informal and to be able to, depending on audience questions, explore different routes, Choose You Own Adventure style. This means that what is in the document, isn’t exactly what happened on the day. My summary below, blends elements of both to give you an idea of what transpired. There’s more detail in the Google Document.
Starting up and training
Risto was fortunate to have good support from his organisation; he said they are supportive of new processes and technologies that can provide the company with competitive advantages
There are so many advantages with Agile for delivering on time, responding to change and minimising rework that it was easy to make a business case to support it.
Is the cost of doing business inefficiently or ineffectively greater…yes.
He stressed the importance of training for his team and also for himself:
If I’m supposed to make decisions about agile I needed to be do the same training as the team
Risto said that he had known agile/Scrum for a while, but had an impression that it was for people that didn’t like writing specifications or following process. The reality, as he sees it, is that it as disciplined as any other development technique that he has ever used before.
Implementation
When it came to putting the training into practice, he said that:
We chose an existing project that was well understood so we could apply agile techniques, to make sure we stayed on track.
Although, he also said that there is something to be said about getting all teams to dive right in, so that they are learning together, and aren’t our of sync.
When asked about how he communicated different ways of working to the management team:
The real issue is getting the management team to be comfortable with a process that doesn’t require detailed requirements up front to work. Once you take them through it and get them involved, they quickly understand just how much insight they have over the product being developed
Gripping the pen
When asked how using Scrum changed what he did as a manager he had an interesting analogy, likening past management as holding a pen palm side down; you keep control by gripping tightly. With agile approaches, you hold the pen palm side up, allowing you to relax your grip but still provide support; giving you opportunity for regular inspection but not forcing solutions on the team. Reduced micro-management frees up time during Sprints to allow a manager to look at big picture items, and help to remove barriers for the team.
On Coaching
Risto’s view is that Scrum is simple to learn the basics of, but there is a lot of “devil in the detail”. Trying to work this out on your own takes time that is reduced by having someone who can guide you through it.
Having an agile coach completely mitigates this as they help guide you through the minefield which means you get to the other side without blowing up too many. I couldn’t imagine professionally introducing Scrum without an agile coach or experienced staff.
Conclusion
When asked, “How has what you have done improved the way you work?”…to paraphrase, his response was:
Everybody is generally happier with the way things work
Job done!
Thanks to those who attended the session, and who joined in the discussion. We seemed to have a decent level of feedback at the end of the session, with a majority of people getting value out of it.
Finally, thanks very much to Risto for collaborating with me in putting this session together.
By Ed Wong This slideshow requires JavaScript.
A little bit of time has passed since my trip to Sydney to present at, and to participate in the inaugural Scrum Australia conference on 10-11 April. This article is a quick run down on what happened. I’ve also detailed the session that I spoke at, in this article.
General Impressions and presenters
The overall impression was that the organisers outdid themselves, creating an efficient, stimulating, collegiate atmosphere. At first sight, I thought that the NSW Teacher’s Federation conference centre might feel a little cramped, especially in the common areas where people would congregate for breaks. This turned out to be OK, though.
I didn’t take very many photos, but I’ve put a few in the slideshow that you can see at the top of this article.
The quality of the presenters was high. Kenny Rubin, over from Colorado, was the star overseas striker. His stimulating opening keynote, was titled “Economically sensible Scrum”. He also did another well considered and delivered talk, “Portfolio Management with Scrum”.
Here is Lynn Cazaly’s sketch notes of Kenny’s keynote:
It was gratifying to see many faces from the Melbourne agile community speaking across the 2 days. In no particular order, I spotted Herry Wiputra, Francisco Trindade, Anton Rossouw, Craig Brown, Bernd Schiffer, and Adrian Fittolani. You’ll spot some of these faces at Melbourne meetups, and other events like LAST Conference, and Agile Australia, indicating the strength of the community here.
Open Space
A valuable addition to the program was the morning of Open Space, on day two. For space reasons this was divided into beginner level groups, and experienced practitioners in separate rooms. It would have been nice to have had enough space for all of the conference delegates to create one, large Open Space morning. However, having said that, the format really led to a wider level of participation than is possible with just sticking to speakers standing at a lectern.
My session
The session I ran was with Risto Pearce, who is the Development Manager at Toll Global Logistics. I coached his department through an agile transition; helping Certified Scrum Trainer Rowan Bunning, with the a couple of the training courses they attended, and then going on to work with the Toll team through the first few months of switching to putting into practice what they had learned.
We did this in a fireside chat/talk show format. With me being the interviewer and Risto answering questions, and both of us giving insights. Here’s more detail on what happened, including the Prezi presentation and the notes for the session.
I’m a glutton…for meetups
Despite being somewhat drained from 2 days of talking to people, I headed straight from the conference to a meeting of the Sydney Business Analysts group. Craig, Renee Troughton and I led a session asking, “What is an Agile Business Analyst?”. The format we chose was a mix of Lean Coffee and Fishbowl, so I called it a CoffeeBowl. Topics were suggested by participants Lean Coffee style, and we used a Fishbowl to discuss it. This worked pretty well, and I’m happy to say that the event has a 5 star rating on its Meetup page 
Thanks to the organisers for having me at Scrum Australia. It was well worthwhile.
By Ed Wong 
I’m happy to announce that I’ve been selected to speak at Scrum Australia 2013, in Sydney on April 10th.
The session is called “Keep on Trucking. An experience report“, and is going to be based upon the time I spent helping with the Scrum training of the development team at Toll Global Logistics, coaching them through their first projects startup, and advising the Development Manager, Risto Pearce.
Risto will be joining me in a “fireside chat”, Q & A session.
The general categories we are covering are:
Origins: What is involved in transitioning to agile in a corporate IT environment?
Training: What type of training was undertaken?
Implementation: How and what happened when implementing agile?
Evolution: What happens after a department has been using agile for a while?
Beyond: How agile affects other parts of a company.
By Ed Wong I was once asked to draw up some guidelines to help steer a team through starting up an agile project. They wanted to have a clear understanding of what was needed to create their initial product backlog. So I fired up Omnigraffle and came up with a few pages that gave an outline for that particular team.
The 3 page PDF covers the following.
- a page with a summary of the phases involved in the process of Product Backlog creation
- a basic Flow diagram, that you can see above
- a page with descriptions of some potential roles/capabilities.
IMPORTANT! – this is a guide only, not a template. It was created for a particular condition, and it should be assessed and adapted to your conditions. I have adapted it slightly and posted it here in the hope that it might be useful if you want to give someone an overview of what starting up an agile project might look like, or to help you if you want to get an idea of what might be involved.
Whatever ends up being right for you, the emphasis should be on communication…doing the right things at the right time, for the right reasons; and making sure that the right people are involved at the right time.
The Phases of Product Backlog creation
Here’s a short description of the phases that are included in these guidelines.
Theme ordering/priority
With Product Backlogs, we often talk about the different items as User Stories, Epic Stories, and Themes as a way of helping to organising the different things that a user would do in a finished project. Some people think of Themes as “collections of user stories“. This is OK, however I have tended to think about Themes as high-level categories from which smaller user stories will be created. At least before many/any User Stories have been created.
For example, “We want to Browse for products, Search for products, See Detail about products, Compare products, Select products to buy, and Pay for them”. So in this case, Browse, Search, Detail, Compare, Select, and Buy, would be the Themes. Some of these we want to do first, or need to do first. This is known as Ordering. It has been known as Prioritization but that Ordering is now the more accepted term. We’ll take the Themes that we want to work on first, and break them down so that they can be developed. Some of the themes won’t be done for a a while, so we can put them aside for now.
Phase 1 – Story Creation
Our goal in this phase is to come up enough User Stories to be able to take them into development and come up with an increment of our product that is tested, working, and might be something that will be usable. Sometimes, there will be some User Stories that have emerged already, sometimes there are just the high level umbrella themes. In this phase let’s get more User Stories out there that we might want to work on imminently.
Phase 2 – Story ordering
We talked about ordering Themes earlier. In this phase, we are talking about ordering the stories that we came up with in the previous phase. It could be that our creative juices flowed so much that there is more work than can be done right away, or that we’ve come up with stuff that we definitely can’t, or don’t want to implement right away. This phase is about surfacing the things we definitely want to take froward and elaborate on in the short term. We’ll put the other stories aside for now.
Phase 3 – Acceptance Criteria
Now that we’ve go the likely candidate stories, let’s figure out what it would mean for the story to fulfil the needs of the user. This is stuff like “I typed the term ‘AA Battery’ into the Search box, then clicked Search. The results would come up in alphabetical order based upon the product name”. There might be several of these Acceptance Criteria, which are sometimes known as “Conditions of Satisfaction”
Phases 4 and 5 – Prototyping and Front End
Even if we have a User Story or three, and some Acceptance Criteria. In order to actually work on it, the team will often need to know more. In Extreme Programming (XP), the information would be communicated with face to face conversations with the customer at the time of implementation. In these guidelines, I show some other inputs that might help the team to implement the stories effectively. In this case, prototyping was used to help to add understanding in the team about how the stories would work when implemented. The User Centred Designer would also work with the Front End Developer who would produce front end code that would be passed to the the developers.
Phase 6 – Bundling
This is simply, making sure that everything is together and at the point of readiness. We don’t want to start developing the stories, only to find out that some of the info that is needed, hasn’t been done.
Download and related post.
PDF
 Product Backlog Creation guidelines (288kb)
Related post
Creating a Product Backlog: Story Mapping. I also have a post about Story Mapping, a Product Backlog technique that I think is useful. It also talks more about the concept of having enough detail to work from for upcoming work, but keeping things at a high level for work that won’t happen for a while.
By Ed Wong 
A service that I offer is training courses for people entering into or who have started to be involved in agile projects. I know when I first started on an agile team, going on a training course really helped to put all the pieces together, in a way that reading books and articles couldn’t quite match.
Agile Business Analysis course
I have developed a course called Agile Business Analysis. The 2 day course covers the principles underpinning agile development, and how as a business analyst you can be involved in agile projects in the following areas:
- establishing project vision and needs
- understanding your users
- User stories, story mapping and Product Backlogs
- Planning and Estimation
- quality and project governance
- solving BA challenges
- continuous improvement
Practical activities are used throughout the course; you will envision a product, and progress through different approaches to build a shared understanding of that product vision. As an advocate of agile/lean User Experience techniques, I include a good amount of content from that discipline.
This course can be run in-house, and it is also run publicly at various times during the year.
This course should also be eligible to be counted towards continuing education/professional development units requirements of various professional qualifications. I can provide you a certificate of attendance, should you need one.
Would you like to know more?
To find out when the next public course will be held, or to enquire about an in-house course, please contact me
|
|
May 5th, 2013
Category: 
Tags: 
