Showing posts with label Agile Methodologies. Show all posts
Showing posts with label Agile Methodologies. Show all posts

Thursday, 21 November 2013

"Well Run Retrospectives for Scrum and Agile Teams" - Article by Mitch Lacey

I came across with a Mitch Lacey's article about how to run useful retrospectives.

In my experience, retrospectives can become rather painful, either due to the extensive length of the meeting, or to endless debates, or any other not-so-agreable reason.

However, much can be made to improve the quality of these meeting, and consequently to allow the team to benefit more of them. You just have to want to improve :)

Here's a brief description of the article.

In general, the article leaves the following notes:
- Retrospectives are a key part of a Scrum team’s inspect-and-adapt cycle. (keeping track of the continuous improvement approach)
- The retrospective is the sole opportunity for team members to examine how they work and how they are working together.
- Retrospectives in Scrum […] give teams the opportunity to change behavior and team culture.
- They are a safe place for team members to share, constructively, feedback with others on how their actions (or inactions) impact the quality, morale, and attitude of the team.

Author sugestions on how to improve Retrospectives:
- Choose a facilitator, which should plan ahead the meeting
- Physical Setup: sugests standing-up in the meeting (don't find it very practical when you have lengthy meetings...), display a timer to control each time box
- Define Ground Rules - suggested ones:
   Be respectful.
    Do not interrupt.
            Put away laptops and phones.
            Park long discussions in the designated lot.
            Recap what you hear to ensure understanding.
            What is said here stays here.
- Run the retrospective with 'only' the team: the author suggests not inviting recursively the PO in some scenarios
- Collect Data in the first 15 minutes or so: we use this time to write the tipical post-its
- Prioritize Data: choose the more relevant items to discuss - the author suggests the use of virtual currency - People spend their currency on the items they want to discuss.
Make a Plan & Choose a Driver: after prioritizing the items, define timeboxes of discussion based on the time left. After the discussion of each item, ask “Is this something we are going to mitigate/fix or not?”. Register the agreed mitigating action o why the item will not be addressed
- End the Retrospective - do the wrap-up with rapid question punctuated from 1(-) to 5(+), like: “how was this sprint?” and “what do you think next sprint will be?” – more important than the answer, the author suggests to be attentive to the non verbal language. When he notes a team members disconfort of any sort, he addresses it in particular. If the person says everything is ok, the author lets it go, and observes the team during the sprint.

In general, I should say that the goal is to get the most out of retrospective meetings, understanding what we can do better in the next sprint. That should motivates us either to continue doing better, and ultimately, giving a sense of involvement in the team goals, making each team member feel it's importance at the team.


Enjoy! J

Friday, 8 November 2013

Business Analysis Pareto's Principle


One of the fulcral point of Agile is: instead of worrying with the development of the whole solution, develop just enough features.

This approach meets the well put Pareto's Principle of 80/20. In a free interpretation, it means that 80% of the problem is resolved with 'only' 20% of the effort, that is to say that we don't need to develop 100% of the a priori requirements to meet the needs of the clients.

See more: http://management.about.com/cs/generalmanagement/a/Pareto081202.htm

Monday, 4 November 2013

User Stories too long? Split them!

If a story is too long, break it down in smaller stories.

But what is to be considered a big story? And how to split it in a way that is logical?

Here's a very interesting roadmap one can use to break stories using a logical approach:
http://agileforall.com/wp-content/uploads/2012/01/Story-Splitting-Flowchart.pdf

Further reading about breaking User Stories can be found here:
http://blog.gdinwiddie.com/2011/05/01/splitting-user-stories/
http://www.richardlawrence.info/2009/10/28/patterns-for-splitting-user-stories/
http://www.infoq.com/news/2011/04/how-to-split-user-stories

Enjoy! :)

Thursday, 31 October 2013

"What is Agile -10 Key principles" - Article on All About Agile


The All About Agile site provides an interesting article about key principles in Agile Methodologies.
Here's a brief summary of the article.

From my use of various agile methods, I have written about 10 key principles of agile.  These are characteristics that are common to all agile methods, and the things that I think make agile fundamentally different to a more traditional waterfall approach to software development. 

They are:
1. Active user involvement is imperative 
2. The team must be empowered to make decisions 
3. Requirements evolve but the timescale is fixed 
4. Capture requirements at a high level; lightweight & visual 
5. Develop small, incremental releases and iterate 
6. Focus on frequent delivery of products 
7. Complete each feature before moving on to the next 
8. Apply the 80/20 rule 
9. Testing is integrated throughout the project lifecycle – test early and often 
10. A collaborative & cooperative approach between all stakeholders is essential

Source: http://www.allaboutagile.com/what-is-agile-10-key-principles/

Wednesday, 30 October 2013

Agile User Stories - Always "INVEST"

In Agile Methodologies, user stories are a way of implementing a set of principles that enrich the methodology application in projects, and ultimately, enrich the way we work.

Those principles are sumarized in the acronym INVEST, that help to define the story quality and even concluding it is poor/deficient, and therefore should be redesigned.

In order to qualify as a quality story, it should be INVEST, that is to say:
- Independent (from all other stories)
- Negotiable (it is not a fixed and unflexible set of criteria)
- Valuable (it must add value to the functionality to implement)
- Estimable (in a realistic approach)
- Small (it must fit in an iteration, and preferably not fill it completely! :) - see more on tips on splitting stories)
- Testable (ensuring with no doubt that it is implemented without bugs)

See more: http://guide.agilealliance.org/guide/invest.html

And have fun! :)