Thursday, 21 November 2013
"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
Do not interrupt.
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.
Wednesday, 20 November 2013
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
Tuesday, 19 November 2013
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! :)
Monday, 11 November 2013
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/
Friday, 8 November 2013
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
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:
Further reading about breaking User Stories can be found here:
Thursday, 31 October 2013
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.
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
Wednesday, 30 October 2013
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! :)
Tuesday, 29 October 2013
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::
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.
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! :)
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.
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!