Are you CREATIVE in your work??

How is our creativity doing has we go to work every day??

"Business creativity is all about finding fresh and innovative solutions to problems, and identifying opportunities to improve the way that we do things. As such, anyone can be creative, just as long as they have the right mindset and use the right tools."

Creativity is a vital tool to evolve in any area, since it allows you to go further beyond your boundaries. And great discoveries were and are made precisely beyond personal boundaries.

In that line of thinking, creativity is an important resource to explore your professional potential and in the process motivate you to do better. And still have fun with it!

Check your levels of creativity, with an interesting quiz shared by MindTools: http://www.mindtools.com/pages/article/creativity-quiz.htm

Enjoy!

"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.

Here's the link: http://www.mitchlacey.com/blog/well-run-retrospectives-for-scrum-and-agile-teams

Enjoy! J

In Scrum, make "Recommendations, Not Rules"

I stumbled into an article from Mike Cohn at Mountain Goat Software while I was searching about rules(...) in Agile, particularly in Scrum.

I recently came across a lot of rules in implementing Scrum, and firmly believe that Scrum is useful because of it's informal nature.
By being informal doesn't mean it is easy-going or irresponsible.
But Scrum is based in the fact that team elements are involved in making the work "work". Remember the pig-and-chicken parabole.
If you define a big set of rules, you will get the work done, for sure. But you will have in your teams either "yes-people" or "grumpy-people". And neither is Agile. Neither is involved. And neither is working in continuously improving, therefore, you are killing Agile.

So, in implementing Agile, go for the basic rules (see Mike Cohn's article bellow for basic rules suggested) but beyond that, just make recomendations. And above all, listen to your teams members.

For implementing Agile in big departments, you can read more about SAF's and other agile frameworks.
It can be big and still be Agile ;)

Here's the link to the article: http://www.mountaingoatsoftware.com/blog/recommendations-not-rules

:)

Continuous improvement in DevOps Teams

 Teams are often overburden with operational tasks, making it difficult to plan development tasks, due to the the operational reality.

InfoQ presents an article/interview about this theme. You can find it here: http://www.infoq.com/news/2013/11/behr-continuous-improvement

In the article/interview, a roadmap is described as a way to continuously improve the way the Team works:
1. Diagnose the reality
2. Make bounded experiments using working techniques
3. Identify target conditions
4. Analyse results, so as to continue improving

The article presents some tools that can guide through this work, such as Theory of constraints, Cynefin, Current reality tree, Improvement kata, Root cause analysis, ...

Try it out! :)

SAFs

The Scaled Agile Framework (pronounced “SAFe”) is an interactive knowledge base for implementing agile practices at enterprise scale.

The “Big Picture” graphic highlights the individual roles, teams, activities and artifacts necessary to scale agile from the team to program to the enterprise level. Clicking on each icon takes the user to an Abstract and a Detail page which elaborates on that element. Some elements (like DBT and Metrics) bring up additional sub-domains with navigation to further depth and description.

Explore more on the theme: http://scaledagileframework.com/

Enjoy! :)

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

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! :)