Still more scrum ..

One more post about Scrum and then we will move on. I promise..

We saw what scrum means and how it becomes an extremely useful means in any Agile implementation. I'd like shed some light on situations where some adjusment might be needed to achieve full potential of Scrum.

From my professional experiences, there could be situations in a project, where on a particular day in an Iteration, the team gets bogged down by issues and can't deliver goods for that day. This is very common in Data Warehousing / Business Intelligence (DW/BI) projects. I personally have spent a few days in succession where nothing significant was achieved. That doesn't mean that team wasn't working. The team was super busy but they were chasing issues beyond their control, for that matter anyone's control. There could be dependencies on the other teams and if those other teams aren't Agile, the situation becomes a bit messy. The reasons are endless. The key in these situations is to hang in there and stay plugged in. Eventually the issues would be resolved and work would be DONE. You can quote me on this..!. 


The job of the Scrum master in these situations becomes very crucial. She needs to be aware of all the issues that team is facing and make sure that they get what they need to keep making progress. Another crucial point in these situations is to have regular contact with the Product owner and the other stake holders, so that they are on the same page. In almost all the situations, they understand and co-operate very well with the things and even try to help the team.
Trust me with proper communication and follow up things DO start falling in place and the team does get back on track from schedule point of view. 

More Scrum !

We introduced ourselves to Scrum in the last post. Let's understand it in more details. If understood, executed and implemented well, this thing can do wonders to any Agile project in any organization with any kind of business. 

Scrum is so flexible and adaptive that it can be literally applied to all the organizations and businesses irrespective of their location, customer base, culture and history.It allows the Product owner to break larger deliverables into product backlog stories to be completed within new few sprints. Scrum master then takes these stories and divides into smaller,measurable 1 or 2 day worth of tasks, during the planning meetings. The team members work on these tasks in the given iteration and deliver a working product at it's end. This gets repetitive in nature till the final product is released.

At my current project, we divide the tasks to a granularity of 1 day, so that all the team members can have an achievement at the end of each working day. The same can be burnt up on the sprint burnup chart. This gives Project Management office (PMO) & the upper management a great deal of visibility about the direction in which the project is proceeding.

Some scrum lovers even go to an extent of saying that Scrum allows an organization to build an homely work culture where each family member has a definitive role to play and they all exhibit co-ordination and collaboration to overcome any difficulties by their fellow house mates !!. I completely second this feeling. It's no exageration by any means at all.

To read more about scrum feel free to visit following great resources,

http://www.scrumalliance.org/pages/benefits_of_scrum

http://scrummethodology.com/

Scrum

As per a few suggestions, I will be talking about SCRUM in my next few posts.


Scrum is one of many Agile methodologies. There is nothing right or wrong with any of these methods. Most of the AGILE places I am aware of go with Scrum though.

Broadly speaking there are 3 fundamental roles:
1) Product Owner
2) Scrum Master
3) Team member


1) Product Owner is an extremely important stakeholder and generally represent business side of an organization. Her responsibility includes sharing the vision of other important stake holders / executives with the team. She would have the highest authority when it comes to making product related decisions and obviously with that comes highest responsibility as well.


2) Scrum Master is the link between the Product Owner and development team. She will be the first point of contact for the development in case of any hurdles.Scrum master should therefor have an excellent understanding of the product being developed and must have a very good idea about the bigger picture. Note that the scrum master shouldn't be confused with the Manager. In most of the cases, Scrum master and development team would report to the same manager. 


3) Team Member An ideal Agile team will have 6-7 cross functional members working towards the common goal of delivering a successful product within the project time frame. This typically contains Software Developer,Designer, Architect, QA-expert / Tester, Database Administrator. Depending on the nature of the work this composition could change a little bit. 


After all we are living in an Agile world where only change is constant :)....

Agile Manifesto

Let's spend some time understanding the history of Agile. This might be a good time to talk about Agile Manifesto....
In 2001, 17 established individuals met at Snowbird Ski resort in Utah to come up with a lightweight software development methodology as against the heavyweight tradition waterfall method. They came up with the Agile manifesto(1) that states, 
"We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value:

• Individuals and interactions over processes and tools     
• Working software over comprehensive documentation   
• Customer collaboration over contract negotiation
• Responding to change over following a plan
  That is, while there is value in the items on the right, we value the items on the left more."
  
  You can read complete history about the Manifesto at The Agile Manifesto(1)

More Agile characteristic..

Another important characteristic is Co-location. Agile puts tremendous emphasis on face to face communication. So normally all the team members are located in an open office space more like a bullpen. This is different than traditional cubical sitting arrangements. This facilitates easy communication within the team members. Normally, the managers would also have a spot in the same space (of course by the window .!) . In cases, when the members have to be in different physical locations, they use all the latest and greatest advancements in communication technologies.

Typically such a common area will have a bunch of desks, with a couple of drawers for the developers . There would be a few rooms for spike, scrums ( stay tuned for more about these in later blogs) purpose and executives offices in the corner. This makes it extremely easier  for anyone to walk into a director or VP's office ( don't push it too much though :P) in case of any issues or problems

p.s: It takes a while for everyone to get adjusted to this kind of set up, eventually the team resources see benefits of co-location ( I didn't say 'put up with' ... :P

Agile 101 !!

I am sure by now there is enough interest and curiosity about Agile methodology. Experts are convinced that Agile is more of a software development methodology than a Project Management methodology. It's assumed that PMBOK, the ultimate word in any PM's world is applicable to only traditional waterfall methods.

Here is an interesting article from Project Management Institute (PMI) website,
Click here to go to the link


Click here to go to Wikipedia

Agile 101 !!

Diving further into more details, Agile methods break tasks into smaller chunks of stories that could be better managed. Normally, Agile groups work on a regular interval of time called Iterations. Depending on the project and the organizations, Iterations could vary between 2 to 4 weeks. We are currently on a 2 weeks iteration planning. The team size is smaller, so that everyone on the team is more focussed and is aware of all the things happening in the team. Basic idea is to plan the iteration in such a way that all the decided tasks can go through complete SDLC cycle of Analyzing, Designing, Coding, Unit and Acceptance testing. That's right, all of it in a single iteration and as you might have guessed, if the team successfully achieves that in an iteration, what you have at the end of the iteration is a release with no or minimal bugs. It might take more iterations to successfully add significant product launch. Add a few iterations like this and there is the final , ready to be launched product at the end... ! wow, isn't that awesome.....