Invest in people!(?)

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

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

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

Business Analysis Articles & White Papers

There is a lot of information throughout the internet about Business Analysis, Business Analysts, BPM, BI, and so on.

Below are some links where one can consult a variety of articles and white papers on these matters. In some case, you can submit your own white papers, if you wish to.

Here it is::
https://www.batimes.com/business-analyst-white-papers/
http://www.infoq.com/articles/?utm_source=infoq&utm_medium=breadcrumbs_feature&utm_campaign=breadcrumbs

Enjoy! :)

BABoK - Business Analysis Book of Knowledge

"The International Institute of Business Analysis (IIBA) is an independent non-profit professional association serving the growing field of business analysis." (http://www.iiba.org)

In line with other 'BOKs', IIBA launched the the Business Analysis Book of Knowledge, a kind of guide about Business Analysis as it is done all over the world.

As an extension to Agile Methodologies, IIBA launched recently the Agile Extension to the BABOK Guide, developed in collaboration with Agile Alliance.

You can find both in here:
BABOK Guide: http://www.iiba.org/babok-guide/babok-guide-online.aspx
Agile Extension to the BABOK Guide: http://www.iiba.org/babok-guide/Agile-Extension-to-the-BABOK-Guide-IIBA.aspx

Unfortunately, thorugh the IIBA site, the BOK is not free of charge. You can read the Preface and Glossary for free, but that's just about it.

HOWEVER! :)
You can read a copy of BABOK Guide Version 2.0  for free: http://www.babokonline.org
The same goes for Agile Extension, also available for free: http://austin.iiba.org/download/presentations/The%20Agile%20Extension.pdf

Therefore, take a look and enjoy! :)

The role of the Agile Business Analyst

In Agile, the role of the BA has some adaptations when compared to traditional approach, in order to respond to client demands in an Agile approach.

Cottmeyer & Henson at VersionOne defend that the BA be the bridge between the product owner and the technical team. In the authors' published white paper, the role of the BA assumes this actor has a good knowledge of the system, and outlines functional requirements from the product owner, translating it to technical language useful for developers. These skills demand that the BA has a good understanding of software architecture concepts, in order to bring good specifications to the development team, so that the business needs are met.

In the Agile way, this process is done by identifying small amounts of functionalities, in an incremental approach (the agile approach), so that small product-ready developments are presented to the clients.

In order to specify robust specifications, the BA accepts input from all the team members, in opposition to receiving it only from the product owner in the traditional approach. This contributes to create a "strong sense of confidence", has the authors defend.

This change on the mindset of the BA can be challenging, coming from traditional project management approaches, but as Cottmeyer & Henson defend, it's an excelent way of creating "opportunities to learn more about how to write feature driven requirements".

Introduction to (my) Business Analysis Notepad!

In this blog you will read about some practices on Business Analysis has they are done throughout the world, since we all learn from each other.
Links are included to the original sources of information.

The Business Analysis Notepad Blog intends to be precisely that: a notepad with notes on everything found regarding the 'science'(?) of this metier!

Hope you enjoy it!