A well oiled machine

I recently did a scrum master certification with scrum alliance, and the 2 day course somewhat changed my opinion of what Agile is and what a scrum master should be.

When talking agile, there is a multitude of beliefs and behavious implemented across a broad range of industries. Some are as little as the use of stand-ups during development to full blown "to the letter" implemented as described in many literature found on the inter-web.

My previous view on Agile was focusing on the work, and what it meant to be Agile, adapting to change and incorporating change as you go. However, after this 2 day course and during the time I was working as an Iteration Manager, I came to see that Agile is much more than that.

The key benefit of Agile, is actually the focus on building the team, the retrospectives and inwardly focused self review. Being Agile and adapting to change is a given, but a team that truly embraces Agile is highly effective and efficient team.

I saw this on the last project I was on, leading a team previously working using a waterfall approach. Each team member would complete their work and pass the work item /tickets over the fence from BA then to the Dev then to the Tester then into UAT. The transformation that occurred during the project when everything was a team problem was amazing. It stopped just being a race finish your own bit and passing it to the next stream, to total ownership from BA all the way through to UAT.

The scrum master's / Iteration Managers role then becomes one of trying to build this understanding in the team. Yes, you still need to work on resolving blockers and helping where you can to streamline the output. But more then anything the scrum master must try to bring the team together, to instil a sense of ownership, not just in "my part" of the story, but ownership as a whole for the entire delivery of a story. This is the hard part, and this is the key to increasing efficiency.

Its amazing, once the team takes ownership of the entire life cycle of a story, it becomes effortless to incorporate change and still make deadlines.

The key to this is ownership. I am currently working in a very waterfall project, we meet with the leads in each area and discuss what the development and test team is going to commit to. We have no basis on which to perform this estimate except experience. we have no buy in from the development team, because they have no say. In my opinion this is a sure fire way to kill all enthusiasm in the team. It becomes a task they have to do in a ridiculously short amount of time, and if they fail.... well they didn't really commit to it in the first place.

On the other hand, a well oiled Agile team, will re-arrange work items, re-arrange what people are doing in order to meet the timeline, and if they truely can not meet the timeline, then it goes into lessons learned and something changes during the next sprint so it doesn't happen again. Agile does not ensure you don't miss deadlines and make no mistakes. Agile makes people aware of what they are doing, how they are doing it and what they can improve on. This constant want for improvement comes from ownership, ownership of the tasks and ownership in the direction of the project.

Comments

  1. Anonymous25 March 2013 at 14:16

    It's difficult to find experienced people on this subject, but you sound like you know what you're talking about!

    Thanks

    Check out my homepage - pikavipit ilman puhelinta ja luottotietoja

    ReplyDelete

Post a Comment

Popular posts from this blog

What good looks like!!

Image
I think back to my favourite places to work, and wonder what made that place so memorable? What have I been pursuing every since then. Is it great new tech? is it working on interesting problems and solutions? Is it learning off great team member who think differently?  It is all of the above and more. Over the years I have worked at many places and had some hits and some real misses and realised what I really enjoy is working with people who are nice and make it a pleasure to come to work each day. This doesn't just somehow magically happen, this culture is specifically created by the leaders who foster it. I hear a lot about servant leader or empowering teams, but what does this mean exactly? As a leader, if your focus is on the success of the business. The solution comes first, must be the best, we can not compromise on quality, must be done quickly. You may get a good solution built, but you may also burn through people. If people leave, the vision is diluted and the new team m...
Read more

A microservice journey - part 2: what type of micro service are you?

Once we established we were on the microservice path, the question of just how would that look came up? We had established the problems and understood what we were trying to achieve, but what exactly is a microservice, and how do you go about building it? The importance of the first step can not be understated enough. If everyone understands the problem and really gets what we are trying to achieve, then microservices write themselves. Well not really, but by understanding what we are trying to achieve, the solution options can be assessed around a set of questions which would help drive the decisions being made. Can this service be deployed on its own, without affecting other parts of prod? If we had an influx of users using this feature, can we scale it out independent of the other components? If we did need to scale it out? do we need to scale out any other components as well? What happens if we had a network issue? would it still be able to do its job? If this service did ...
Read more

Validation Rules

Every business application must incorporate some kind of business logic and validate the response received from the user. There are a few ways to incorporate this logic through your application, which involve a mix of client and server side validations. This often means you will have some validation in your UI layer as Field validators and some logic in your business tier, where it is just not possible to bring to the UI such as verifying a date range does not overlap another set, or something which needs to access the database to verify against. The Validation Rules library attempt to unify this disparate approach to validation, and to automate some of the simpler validation logic such as required fields and field length validation. Instead of putting validation through the tiers, we can simply implement IValidation on the business object. This interface attaches a meta list of rules to the entity which we can build in the business layer and will propagate through down to th...
Read more