Posts Tagged ‘Agile’

« Older Entries
Newer Entries »

Spin your Wheels or Drive on Purpose?

Tuesday, November 23rd, 2010

Author: Jonathan Coleman

The Retrospective Itself

Theme: Spin your Wheels or Drive on Purpose?

I make no apology for this – I borrowed heavily from the YouTube Footage of Ken Block, the Rally Car Driver (especially this one)

9:00am – 9:05am Welcome and “Focussing question”

I welcomed the team to the retrospective – and thanked them for putting aside the time. I then asked the following question:

“How do we spend less time spinning our wheels, around issues and more time driving with purpose?”

9:05am – 9:10am Ken Block’s Gymkhana 3 Video on the big screen.

Lots of smoke, spinning wheels, and fancy footwork.

9:10am – 9:20am Quick walk through of the last 15 Iterations.

A quick show of hands of who was here for more than 1 iteration. More than 5, more than 10, back from the beginning!

(I had prepared an iteration timeline with post it notes (stickies) on some of the challenges we had encountered during the iterations. This required pre-work to remember it all).

The team was encouraged (and did) shout out and participate in what we overcame as we walked through the iterations. At the end of this we saw that we had overcome some pretty major obstacles. We were feeling pretty confident that no matter what came our way in the next release – we could tackle it and overcome it!

9:20am – 9:50am Three Laps of the room around the Issues.

I had organised several “stations” around the room with Butcher’s Paper, Sticky notes and whiteboard markers.

During the Iteration Walkthrough, we called out some of the major themes of what we had overcome – but spent our time Spinning Our Wheels vs Driving with Purpose. I then encouraged the team to gather around the hot topics they felt passionate about – and self organise into a group. Shortly after this chaotic time – we began our first “Lap” (i.e. 10 minutes brainstorming on the topic).

After the groups brainstormed ideas to help us overcome similar issues in Release 2 – or how to overcome the still remaining issues – the teams had to stop and select two spokespeople to stay behind – and then move on to the next topic! They had a very short time to get through this. This was also somewhat chaotic and very fun.

The two people left behind quickly introduced the topic to the arriving group – and then left to rejoin their departed group on the next topic.

After 3 Laps – the team had to stop and re-gather at the main wall.

Again they elected two spokespeople who presented the issues back to the group and most importantly – What they were going to do about them!

After this Retrospective – we wrapped up with a short summary, and I ended it by thanking them for attending the session, being honest and openly sharing their thoughts and actively participating. We then had a morning tea to celebrate the change in phase for the project, and everyone applauded the group and the retrospective.

Tags: , , ,
Posted in "A" Teams, Agile | 2 Comments »

Running a Successful Large Scale Retrospective

Friday, November 19th, 2010

Author: Jonathan Coleman

The first thing I can say about running a large scale retrospective is:

It takes PREPARATION!

I’ve been sweating on this for a while. In our particular project we have about 70 people involved on a day to day basis. Previous retrospectives have involved the whole team at once resulting in retrospectives dragging on, and most people leaving on a low note.

So as part of my role as Iteration Manager, I have to be willing to accept feedback and seek help!

As a result of the realisation that I generally suck at facilitating large crowds! I attended the Agile Academy’s recent Facilitation Course presented by James King in Brisbane.

This was an extremely valuable day for me! I learned some great tips and tricks, and the Q & A session was focussed on the large crowd retro issue. The essential thing I learned was that Preparation would be key to ensuring a successful outcome which we could learn from and avert disaster and a waste of time.

So in the preparation phase, I

  1. Set up 7 Stations around the room with butcher’s paper – stickies and whiteboards;
  2. Mined the last 15 retrospectives for recurring themes and challenges;
  3. Prepared a video for viewing on large screens;
  4. Booked the meeting room and sent the invite out so the right people would be ‘at the table’.

Tags: , , ,
Posted in Agile, Agile Transformation, Collaboration, Continuous improvement | No Comments »

The Games Agilists Play

Monday, November 15th, 2010

Author: Susan Akers

Games are always a terrific way to get people relaxed and willing to learn. All you need to do to see this is just to step into any room at a lunch break at a conference with a group of Agilists!

Mary Gorman, the author of Playing at Work: Games that deliver value on Stickyminds.com says “You can learn from games, use them to instigate change, innovate, and make product decisions.” She goes on to suggest a range of games, how to play them and what value agile teams can get out of them.

Really it is all about having fun and letting your inner child run free in its creativity.

Mary also has a link to her excellent blog on Being Agile when Designing and Playing Agile Games where she actually links the Agile Manifesto and the 12 Principles of Agile to designing an Agile game.

So get playing!

Tags: , , ,
Posted in Agile, Collaboration | No Comments »

Agile’s Secret Sauce – Part 3

Thursday, October 28th, 2010

Authors: Tracey Kay and Julian Coldrey

As project leads, we bring a certain perspective to how we have achieved the team culture described in Part 2 of this series.

So here are some things we did as a project leadership team that seemed to get a good result:

  • We picked the right people. It’s not about assembling the best, most high achieving collection of people. It’s about team fit and picking a group of people who work well together and, as a team, EXCEL.
  • We let the team self-select almost everything. Nothing says empowerment like the ability to choose how you work, what you work on, and who you work with. By enabling our teams to self-select and organise around our goals, they took on the choices as their own and were much more inclined to make them work (or even better, change them when it was obvious they weren’t working!)
  • We eliminated Leads to create accountability. It may seem counterintuitive to drive accountability by eliminating leads in an Agile team, but past experience showed us time and time again that creating leads for each skill set (“Dev leads,” “Test leads,” “BA leads”) caused an immediate diminishing of accountability with the rest of the team. We felt that if someone was given the “lead” role that it flew in the face of the culture of shared accountability we wanted to generate, so no leads became the order of the day.
  • We chose a specific leadership style. Leadership is always important, but in an Agile environment where empowerment and self-direction are critical to success, choosing the right leadership style is paramount. We decided to provide leadership that focused on the vision and purpose of the team, but which was not directive in terms of how to achieve these goals. In other words, our mantra was always “this is what we need to do, now let’s figure out how to do it as a team.” This really empowered the team, got everyone thinking, and ultimately helped create the sort of culture we were looking for.

We hope some of musings in this three part series about what makes up Agile’s secret sauce has resonated with your experiences of building high performing Agile teams. If we could take one thing away from this project experience, it’s that we’ve never regretted any investment we made into building a healthy team culture, as it has consistently been repaid in the form of a fantastic, high performing team who have fun!

Feel free to send us your Agile recipes for success too or direct us to other good blogs/articles.

Tags: , , , , , ,
Posted in "A" Teams, Agile, Agile Transformation, High performing teams, Innovation, Self organising teams | No Comments »

Agile’s secret sauce – Part 1.

Thursday, October 14th, 2010

Authors: Tracey Kay and Julian Coldrey

Welcome to Part 1 of our series on a real case study of working Agile and what we have learned.

Let’s be clear right from the beginning, WE ARE fans of Agile. After going on a multi-year journey from the warm, cuddly, but ultimately illusory security blanket of Waterfall to the extreme sports vibe of a functioning Agile environment, we know the benefits of Agile first hand. Team empowerment, distributed problem-solving, stepping up, across, and even — occasionally – down; Agile is simply a great way to get things done! We’re currently working on a large, geographically distributed project to deliver a snazzy new insurance claims system. Challenging as it has been, we don’t know how we would have made it to the point where we’re at, almost ready to drop our first production release only a few months after starting to code, if we had been working any other way than Agile.

As much as we dig storywalls and retrospectives, we don’t credit our progress to Agile practices. Sure, Agile has a great toolkit of techniques that can help the team understand and manage what needs to be done but …… teams with low Agile maturity often hone in on the more tangible aspects of the methodology: standups, story cards and so forth. Yet time and time again, we’ve seen teams go through the motions and ultimately struggle, even though on a superficial level they are doing “everything right.”

SO WHAT IS THE SECRET SAUCE THEN? Put simply: CULTURE and, because culture is driven from the top down (ie. the leadership team) the right culture creates an environment for a productive set of values and behaviours to emerge. It is the culture, not the mechanics of Agile, that infuses Agile practices with the right intent. Culture, not a wall covered with sticky notes, enables sustainable pace, quality and collaboration. In fact, experience tells us that, without an appropriate culture, working Agile is pointless.

Now that’s a lot of italics, let alone ideas, to cram into one paragraph. And we don’t mean to suggest we’ve nailed it in our project. However, the closer we’ve come to the right team culture, the more effective our Agile practices have been; the better the team has worked; and the more confident we’ve been in reaching our goals.

In part 2, we’ll look at some aspects of the team culture that have helped our delivery the most.

Tags: , , , ,
Posted in Agile, Agile Transformation, Business | 2 Comments »

23 Points of Value Please

Monday, September 27th, 2010

Author: Daniel Ginn

When I go grocery shopping I often think to myself ‘This would be a breeze if I just picked one of everything in the store, I’d never have to worry about forgetting something or having something I didn’t realise I needed. I then realise how much I have in my wallet and think ‘actually I think I’ll just get what I need’. Seems logical, so why do I still see projects with every story being a MUST HAVE. Has someone borrowed dad’s credit card?

Seriously though, the beauty of the financial mechanisms that we live with force us to make rational decisions with our money. This rationalisation disappears when we are not spending our own money. Well I believe Agile does offer some help here in the form of value points.

This concept was first introduced to me at the recent Agile Australia conference by Jim Highsmith, one of the authors of the Agile Manifesto, in his keynote address about how we measure Agile success. The idea behind value points is to assign value to features or even down to the story level using business input. The project team can then use this information to focus on delivering the highest business value features/stories to the customer.

So the desired behaviour here is – To get the business to identify what is really valuable to them. But what mechanisms can be used to encourage this behaviour? Well, Jim mentioned a couple of techniques to achieve this.

  1. The first is to use true value, that is, the actual expected benefit for the productionisation of a feature or story. The problem with this is, that it requires a great deal of effort in terms of analysis, and it may not be possible on projects where benefits are not easily defined by a number.

  2. The second method is more pragmatic and uses a relative approach to assigning value. That is, giving the customers the opportunity to assign relative value points to features or stories. By limiting the amount of points that the customer can assign, the customer is forced to consider the relative value of each story against another. The abstract value rating also allows for points to be assigned down to a story level. On smaller projects all stories can be considered together, on larger projects have the points divided at the feature level and then assign the feature level points to the stories underneath them.

You may receive pushback from the business and find that they don’t want to participate. If so, let them know that all effort must measure both cost and benefit before being scheduled, otherwise you can’t be sure that it adds value. Another method the desired participatory behaviour might achieved, is through employing gaming mechanics. This means, make a game out of the value points assignment.

In a recent project, I setup a virtual storefront in which stakeholders could go in and buy stories that were important for them. The participants had two opportunities to buy stories and could see what others were buying in between each “sale”. I think the most critical parts of the exercise though are setting the scenario, making it fun and creating the same limiting conditions that one has when grocery shopping.

Any of these methods will only be marginally effective unless useable software is being regularly released.

By having regular releases you are homing in and delivering on what is most valuable to your business. You never know, the customer might come back after a couple of releases and say ‘Thanks, but for now, that’s all we really need’.

So the next time you see a customer pull out dad’s credit card, value points might be the way to go.

Tags: , , , ,
Posted in Agile, Business | 1 Comment »

Agile – What’s the buzz?

Monday, September 13th, 2010

Author: Daniel Luschwitz

Agile development is definitely the latest trend in software engineering. Over the past 18 months I have had numerous conversations about sprints, stories, sliders, burn charts, wall ware and all the other cool techniques that fit under the ‘Agile’ banner.

When you start to understand these techniques they all make sense so no wonder the IT community is starting to see the benefits that Agile development can bring to an organisation.

The main difficulty though can be ‘selling’ the idea to the wider organisation, but luckily, the solution isn’t hard to find – in fact it is printed as point number one in the Agile Manifesto:

“Individuals and interactions over processes and tools”.

Interesting point right? Believe in your people and empower them to have conversations – revolutionary! So here is my battle plan to make this happen:

  • Become informed.

Knowledge is power, so know how to answer the mirage-hurdles such as: “it doesn’t work with distributed teams” and “regulations mean that we need documentation”. Dispel these myths! Talk to colleagues who are doing it and gather some case studies. Even those pesky sales people that aren’t!

  • Create a buzz within your organisation.

In most cases I see, Agile development is being driven by the IT community so the first port of call is to inform ‘the business’ of what it is all about. If you sell it correctly then they will be driving the change! Think about what you would need to do if you were trying to convert to Waterfall from Agile.

Your ‘sales pitch’ would be something like:

“We are going to organise a team to ask a whole heap of questions about what you want. Once we think we are ready we are going to get started on putting everything together and in 6 months the product will be ready for you. If you want changes/additions along the way, we can do it, but you will need to either give us more time or throw more money at us to hit the release date.”

How much easier is it to say?

“We want you to be a part of the team that is developing this product. Every two weeks we will show you what we have done. You can then give us feedback about you would like and what you would like us to chance. We want to work on the items that are most important to you first up. If you want additional features along the way, no problem, we’ll show you what is left to achieve and you can make a decision on what is more important.”

Support your people with training and consulting and the results will come. Agile to me is a cultural shift in an organisation and first and foremost it is important to get everyone on the same page and manage this transition carefully.

The Agile Academy courses, Taste of Agile and Agile for the Business (choose your flavour) are fantastic ways to create the right buzz about Agile. These courses deliver the message in an informative and fun manner. Where else can you see your IT Executive playing with Lego and blowing up balloons?

As Kylie once sang “Everybody is doin’ a brand new dance now, I know you’ll get to like it if you give it a chance now…”

Daniel Luschwitz is a Senior Account Manager at Software Education, a training partner with the Agile Academy. You can contact Daniel directly at danl@softed.com, 0410 455 040 or follow him on Twitter @Daniel_SoftEd.

Tags: , , , ,
Posted in Agile, Agile Transformation, Business, Unified vocabulary | 1 Comment »

Agile is not a four letter word, but does go by many names.

Monday, September 6th, 2010

Author: Susan Akers

As a non- technical Agilist I am often flummoxed by new terms that seem to be have been created by Agile technical people to talk about Agile and its practices and values. So I thought I would put together a little quick reference guide of terms that might prove helpful.

Please remember, that this is from my perspective and undertanding, so I’d be very happy to hear your comments if you have a better definition. I have completed some basic Agile training but the terms I am talking about here seem to be ones that people use on an operational basis. I also started thinking of providing a full A to Z first up, but it was too intensive for me, so here is what I have come up with, from A to G so far.

A: Agile – is a way of thinking and working. It requires a positive attitude towards collaboration with your immediate team members (or part of a broader team), an openness to embrace change and a willingness to act quickly. The goal being to produce workable solutions your customer actually wants, creating less risk and higher business value. This means quick returns (or iterations) so real results are seen in a matter of weeks rather than months or years.

A: Artifact. (yes, this is correct, not a typo). This is anything you produce during the development of a software or business project lifecycle. These could be – Templates, Diagrams, quick “How to” one pagers, or anything you can reuse for another project.

B: Brown Bag (or Lunch ‘n Learn). Usually refers to a lunch time training or information session (hence ‘brown bag’ to bring your lunch in, so can eat and listen at the same time). Some great examples can be found at: http://bit.ly/c1yPyT.

C: Continuous improvement or Cha cha changing. If you can’t accept change, you might think you would hate working in an Agile environment. But, I’m sure that your team will think and talk about a project when it’s completed, and what went right and wrong and what you would do better next time. Congratulations! You have just conducted an Agile retrospective and are using the Agile practice of Continuous Improvement.

D: Do realise that Agile is not just about software development. Agile, as I mentioned under “A”, is a way of thinking about things which is why our business colleagues have taken to it. They have realised that they could use it on their own projects/tasks and gotten the same positive results about solving issues and continuous improving their process to make it easier and more successful the next time. They have also found that having a standup each morning has stopped the interminable wasted status meetings they once had.

E: Experience reports (also known as Field reports). Often seen listed at conferences. My understanding is that they are presentations where experienced practitioners talk about their hands-on experience and discuss case studies, the blockers they had and the lessons they learned from both their sucesses and failures.

F: Fishbowls. Normally this means getting 3-4 seats in the middle of the room (the fishbowl) with the rest of the team in an outer circle watching. Everyone takes a turn in sitting in the fishbowl sharing their concerns, asking questions, and also discussing proposed solutions. Usually one seat is left empty so that if anyone wants to join the discussion in the fishbowl they can sit in the empty chair.

To ensure there is always a seat vacant, an existing member of the fishbowl must voluntarily leave the fishbowl and free up a seat. The great thing about this is that it gives everyone an opportunity to speak so the discussion doesn’t get dominated by just 1 or 2 speakers. An example can be found at: http://bit.ly/cl1AkM.

G: Go for the low hanging fruit. Make the quick wins. Don’t get caught up in the end solution – cut your project into small reachable goals (wins) along the way and do the easy and quick things to complete, first. Why? Because it makes everyone feel positive, and in spite of what challenges you may be facing you are also achieving!

Stay tuned for the next instalment of H to M. Feel free to send me your suggestions as well.

But for the time being:
That’s how Sue sees it! (Source:GLEE)

Tags: , , ,
Posted in Agile, Keep it Simple, Unified vocabulary | 3 Comments »

The Agile Journey – a Testing Experience!

Monday, August 9th, 2010

Author: Kate Ellery

It’s quite hard to believe that a couple of years ago we were thinking “what’s this new fandangle ‘Agile’ thing they’re trying to push on us?”!!! And how far we have come since. Ask anyone in the team now if they’d ever go back to traditional waterfall projects… boy, if looks could kill!

In testing, we have certainly had many challenges. And we’re still perfecting some of our processes and tools, but looking back, we have come a long way since Agile was an unknown phenomenon!

Areas of Vast Improvement

  • Testers are being involved at the start of projects, instead of coming in when the first iteration is starting;
  • Acceptance criteria is being written against user stories by the entire team (often this was written solely by our Business Analysts), ensuring a common (and accurate) understanding of each story;
  • Collaboration and communication with Business Analysts and Developers has greatly improved, with all team members taking accountability for project tasks;
  • New automated testing processes – what we are actually automating, where we are automating (UI, functional code, shared services), and the tools we use;
  • Co-location – project teams seated together to encourage active collaboration within teams, ensuring any issues or changes are communicated to all as they happen, rather than finding out about them too late down the track;
  • We find that fewer defects are logged, due to the acceptance criteria being used for unit testing – the story must pass this criteria before the card moving to ‘in testing’.

However, this does not mean that we are perfect (yet!). There are some areas where we still struggle. We find the monthly brown bag videoconference sessions with other testing teams around the company beneficial to discuss some of our issues, and learn from others’ experiences.

Areas where we still face Challenges (with a capital “C”)

  • Time – fitting all the testing tasks into each iteration; the main tasks being – test execution (system, functional, integration & regression testing across several environments), planning for the next sprint, automated testing;
  • Meetings meetings meetings!– daily stand-ups, showcases, retrospectives, planning sessions – all very important, but they all take up our “maker’s time”;
    and
  • Getting one project finished before the next starts – we have a 6 week warranty period where the project team supports any production issues, which can eat into the new project tasks.

On the whole though, we all enjoy Agile and our testing team has become a busier, but happier team who are more supportive to each other, as well as supporting other roles in and outsdie the core team. We also feel more appreciated by our team members, as there is a better understanding of what each role does within each project which has resulted in a greater respect for each other as well.

Tags: , , ,
Posted in Agile, Innovation, Testing | 3 Comments »

A FedEx Style Day

Tuesday, August 3rd, 2010

Author: Deb Mahoney

There were a couple of people who have asked me recently about what a FedEx day was as they had heard that my team had recently run one. Well I will say that we did conduct a “FedEx style” event to help us to improve our understanding of Agile and to address technical debt issues.

A FedEx type event is based around ideas from Google and Atlassian (a great Australian company) and is intended to provide participants with an opportunity to think outside the box and to work on issues that are not part of their current work backlog. Additionally, it gives participants a way of practicing their agile techniques by planning and completing a number of iterations in rapid succession. The name ‘FedEx’ is intended to emphasise the rapid nature of the event and the focus on delivery.

So what did we do and how did we plan it?
About 2 weeks prior to the actual event, ideas were proposed on the team’s wiki and collaboratively edited to refine the scope and potential benefits. Of the 14 ideas proposed the list was reduced to 4 based on preferential voting. Cross functional teams were then formed.

The Day Before
A planning session was held to finalise the teams and ensure there was a practical balance of skills (BA, Dev, Test) and to identify resources (desks, seating, computers, software, …) needed to ensure that all team members were able to get a clean start the next morning.

The Day Itself
The teams worked on their topics throughout the day with most teams completing at least 3 full Agile iterations. Some of the Agile techniques used were Stand Ups, Story Walls, Retrospectives, Iteration and Release Planning, Requirements as Stories, Early and Exploratory Testing, Automated Build, Code Metrics and more. By late in the day most teams had working software and were well advanced in preparing for the following day’s showcase.

The Day After
Final touches (and in some cases code changes) were made followed by a showcase session where each team presented what they had achieved. The audience then voted and a clear winner emerged.

The Winner
The winning team developed and matured an existing tool to automate an otherwise manual and burdensome task. The tool provided a capability for bulk updates thereby significantly reducing the time involved to resolve statuses. Since then the tool has become part of the Support team’s set of working tools.

This isn’t the only way to run a FedEx day and I would also recommend that you have a look at Craig Smith’s blog who outlines what he called a Developer Day and as usual Craig provides heaps of terrific sites/videos and other resources to help you out with understanding of FedEx Days.

Tags: , ,
Posted in Agile | 1 Comment »

« Older Entries
Newer Entries »