What don’t you like about Agile

 Technology  No Responses »
Nov 082009
 

“What don’t you like about Agile ?” – I asked one of my team member during our 1 on 1 session.

Flashback:

It has been six months or so since have started using Agile\Scrum practices\methodologies. I wanted to see how far have we got acceptance for the new way of life at grass root level.

But as I asked him this question, I realized that I wanted to answer the question myself.

I thought it may be worthwhile to capture my own thoughts on Agile at this point and then compare afterwards and see what has changed in my perspective.

Of course, much of what I say is influenced by how much I understand Agile and may not be the under-belly of Agile.

So here goes…

1) Drop in efficiency

I think there has been an overall drop in our efficiency . E.g. some of the stuff that we delivered in two sprints, we could have probably delivered in half the time (at least from developer’s perspective). I believe in an effort to have the whole team move together , we put a drag on an individual’s efficiency.

2) Effective communication or excessive communication ?

With the whole team moving forward together, you end up making a conscience effort to involve others in what you are doing.  Sometimes it becomes difficult to distinguish what really needs to be communicated to others and what doesn’t need to be.  This increases chattiness in the team and the lines between effective communication and excessive communication gets blurred. And this has a direct effect on the team’s productivity.

3) Restrained creativity

One thing I truly appreciate about my team is their let’s-do-that attitude. A passion to try out new things. Ability to see a solution behind every problem . Going Agile, this is my biggest fear -  I don’t want the team to loose their creativity  and feel that they need a permission slip before trying something new.

So that’s it more or less for now. I will revisit this after few months to reflect on what has changed in my beliefs

What about you ? What don’t you like about Agile ?

And if you have an opinion on what my concerns are, I will be very happy to hear that.

 Posted by Rajiv Narula at 7:02 pm  Tagged with:

Certified ScrumMaster Training- Review

 Technology  No Responses »
Sep 182009
 

Yesterday I completed my Certified Scrum Master training.

It was conducted by Giora Morein from BigVisible. It was an excellent experience and I thoroughly enjoyed it.

It was a two-day program.

Day one was split into two parts. In the first part , we played some scrum games- which was quite cool actually.

We formed 4 teams with 4 members each.
We were given a series of tasks which we then went on to size , prioritize, and execute.

We simulated two sprints and discussed planning and sizing strategies around that.

I think this was an excellent idea- because it gave us all a common ground to discuss the rest of the session. It also made us- the students closer to each other as a team- making learning a community process- which in turn is quite agile, I think. It also added an element of fun to the whole session !

The rest of the day and the second day- we went through the various parts of scrum- discussing definitions , processes, challenge questions and so on. Giora gave us some excellent examples and definitions and analogies .

The one that I liked the most was- where he contrasted commitment with promise. To quote him-

A fireman makes a commitment that he will do his utmost best to save people from a building on fire. He does not make a promise that he will save everyone from the disaster. In software development- we are not in the business of making guarantees- we only commit.

The sessions were very interactive. We got into some lively discussions and he was very patient and took time to answer us all- without ever seeming rushed. We all brought in our real life problems into discussions- which made the session even more meaning full.
What could have been better…

I would have liked to games we played in the beginning to be bit more detailed and the experiences of the games discussed some what more. And if we had tied down some of our discussions back to those games-it would have been slightly better.

But I understand- we were hard pressed for time and overall, I think we did good in terms of coverage and depth.

Do I recommend this training ?

Yes. I would definitely encourage anyone wanting to learn scrum to attend one of these trainings. It was like reading 5 books in two days and having the opportunity to ask author questions instantly.

 Posted by Rajiv Narula at 8:14 am  Tagged with: , ,

Scrum for developers

 Technology  2 Responses »
Sep 172009
 

To me – scrum is a way of life- and if you are coming from a waterfall- its a very different way of life…
To effectively adopt scrum- we all have to change our ways… this is in fact ,I think the hardest part – to change our work habits and to change our beliefs.

These are my reflections on what a developer needs to do to be effective in scrum. Much of it is based on what I understand about scrum not entirely about what I have experienced in scrum.

Iterative vs Incremental development

Consider that you have a manufacturing plant which makes shirts.
You get a work order of 50000 shirts.
What would you rather do ?

A. Make 50,000 collars first and then 10,000 arms next and then…
B. Or would you rather make 1000 shirts and then another 1000 shirts and so on…

I guess you know – I want you to select B. :)
Actually – a part of me wants to choose A- because that is probably more efficient process.
But would you rather have efficiency or mitigate a huge risk ?

If it was only efficiency I was bothered about- I would probably choose A.
But if it was my dime on line- I guess I would choose B.

To translate this into a software development process…
You have to write a CRUD screens for some object
A. Would you rather do the Data Access layer first , and the service layer and then UI layer ?
B. Or would you do the entire layer first and then keep on adding functionality to the product – across all layers

I have always coded as in A. To move on to B- would be a big shift for me personally.
But its difficult to deny the benefits of this approach.
Quick delivery, quick feedback, less wait time for users, validation team gets to test sooner and so forth…

So while A maybe be better for me as developer – B is probably better for the team in general…

Note: In the earlier example- I didn’t suggest a shirt at a time. You need to find your own balance between the two extremes.

So why is this important in Scrum ? In every sprint, you want to produce a potentially shippable product- 50,000 collars aren’t shippable though 1000 shirts are…

Software development is more than coding
Discuss with a developer a development task- She\he will probably not think beyond the coding part.

For us (developers) ,software development is almost synonym with coding. Everything else- testing, configuration,deployment , data migration – all seem so auxiliary.
But in truth- software development is more than coding.
The other tasks- maybe not as mean as coding (but actually in some case, and I would venture to say often- they are tougher and more complex than coding itself !!!)
We (software developers) need to think beyond coding and consider all that happens before and after the software is made.

So why is this important in Scrum ? Because in scrum- you will see the roles getting blurred.
The key is- it’s team’s responsibility to deliver product ,rather than developers responsibility to code and QA to test and RA to get requirements

If you are a developer- do not hesitate testing what another developer did or maybe contribute to the requirement specs. Quite an idea- eh?

Another things is- in one sprint, you will see the whole life cycle of the software run from start to finish- What was traditionally kept for the last- is now up-front all the time.

Repeatable automated testing

Ah!  This has been beaten to death on the blog world- so I am not sure what else can I add to this- except that you need to have some sort of testing strategy which is repeatable and automated.

THIS is your insurance policy against future breakage.
If you live in Florida- you buy flood insurance
If you are in software development business- you write repeatable automated test cases.

So why is this important in Scrum ? In scrum, you will be doing stories , and its more than likely that you will be coming back to the same module again and again in every sprint.

E.g.  you develop a search functionality in the first sprint and then you add more search features in the next sprint. To make sure that you don’t break what was coded in the earlier sprints- you need automated repeatable test cases

The burden of testing increases dramatically in scrum- which is almost impossible to keep up via manual testing.

Sprints are not mini-waterfalls
So we discovered scrum- and decided to do iterations.

But iterations alone- doesn’t scrum make.

If you have an iteration of analysis followed by an iteration of design and another of development- voila !!! You have created yourself a scrum-ish waterfall !!!

Not sure if you are better off or worse off then before…

Develop small. Develop complete. Develop well.

So why is this important in Scrum ? This actually ties back to my earlier point of  doing iterative over incremental development. You have to do all in one iteration to have a shippable product. Analysis or design alone do not constitute a shippable product.

Note- I am very hesitant on this- I still prescribe to the old philosophy of upfront design. I don’t mean design all the way- but still spend some time designing the software upfront and discuss with peers before you plunge in head long
‘
Are you done ? or are you done-done-done ?
The first time , I heard about this was from my manager about 8-9 years ago.
When we would tell him that we are done. He would ask us back – Are you done ? or are you done-done-done ?
If you replied back saying that you are done- but …. He would stop you and refuse to listen more till you took back that you are done.

To be done but not  done-done-done – carries a huge weight of keeping track of what all minor tasks remain. And if you have whole bunch of tasks that need to be done before you release your product- how realistic is your statement that you are done.
So – unless you are not done-done-done- you are not done.

Developers are smart people. The moment they are done with the challenging part of the problem- they want to move on to the next challenge. But this doesn’t work well with scrum.

So why is this important in Scrum ? In scrum- when you are done with a story- you don’t come back to the same story in the next iteration
You need to move on.
And the only way to do is to ask- Are you done ? or are you done-done-done ?

 Posted by Rajiv Narula at 1:55 pm  Tagged with: ,
 Older Entries  Newer Entries
© 2011 Technology Cafe Suffusion theme by Sayontan Sinha