FitNesse is an acceptance testing framework. It allows business users, testers and developers to collaborate on executable specifications (for example in BDD style and/or implementing Specification by Example), and allows for testing both the back-end and the front-end. Aside from partly automating acceptance testing and as a tool to help build a common understanding between developers and business users, a selection of the tests from a FitNesse test suite often doubles as a regression test suite.
Ever had deadlines that must be met causing short-term decisions to be made? Ever worked over time with your team to meet an important deadline after which the delivered product wasn’t used for a couple of weeks?
I believe we all know these examples where deadlines are imposed on the team for questionable reasons.
Yet, deadlines are part of reality and we have to deal with them. Certainly, there is business value in meeting them but they also have costs. Read more
User stories must represent the business value. That's why we use the well known one-line description 'as an <actor> I want an <action>, so I can reach a <goal>'. It is both simple and powerful because it provides the team a concrete customer related context for identifying the relevant tasks to reach the required goal.
The stories pulled into the sprint by the team have a constraint on size. They should at least be small enough to fit into a sprint. This constraint of story size can in some cases require the story to be broken down into smaller stories. There are some useful patterns to do this like workflow steps, business rule or data variation etc.
When dealing with large and complex systems consisting of many interacting components the process of breaking down can impose problems even when following the standard guidelines. Especially when breaking down a story leads to stories which are related to components deep within the system without direct connection to the end user or the business goal. Those stories are usually inherently technical and far away from the business perspective.
Nagenoeg elk team dat op een Agile manier gaat werken ondergaat een versnelde ontwikkeling. Agile teams ontwikkelen zich meestal gemakkelijk. In de 1ste sprint retrospective zullen de teamleden de teamsfeer en –dynamiek als een van de Goed!-punten noemen. Agile legt onder meer nadruk op samenwerken, technische excellentie, transparantie en het presenteren van behaalde resultaten. Dit geeft een boost aan de cultuur, vorm van communiceren (en met wie!) en het vakmanschap.
Niet alle teams ontwikkelen zich even snel, en niet alle teams lukt het om hun succesvolle groei na de opstartfase door te zetten. Vooral bij een flinke tegenslag, een impediment die voor stagnatie in het development proces zorgt, onderscheidt zich het kaf van het koren. Er zijn verschillende lijstjes als de Zeven Strategieën [Bernstein] of de Vier Ingrediënten [Krishnamurthy] voor succesvolle teams. Hieronder het lijstje gebaseerd op mijn ervaring met succesvolle en minder succesvolle teams.
Organisational Gravity is well-known from the book ‘Succeeding with Agile’ by Mike Cohn and described therein as ‘the forces that pull an organisation back into old habits’ [Coh09].
When an organization makes a transition towards an Agile Organisation and the necessary changes happen at a too slow rate eventually Organisational Gravity will pull the organisation back into where it was before the transition attempt. The well-known property, see e.g. http://mariewiere.com/2012/02/10/avoid-organizational-inertia-dare-to-change/, of an organisation that is associated with how fast the organisation can change on change-triggering events is known as Organisational Inertia. If it is too high it takes a lot of energy to make changes happen and the Organisational Gravity may make it impossible to complete the organisational transition.
Can we use Organisational Inertia as a predictor for how long it will take (on average) for the Agile transition to complete?
Other questions that come to mind are: What is ‘Organisational Inertia’? How do we measure it? What does it tell us? How does it help? Can we change it? And how?
This blog will address the first question: ‘What is it?’.
In next blogs I will focus on how Agile teams affect the organisation's inertia and how to measure it.
A team that I have coached took up and voluntarily committed to a sprint backlog that was not realistic. Worse, not only it was clear afterwards that it was unrealistic, but they knew already right from the start of the sprint. How come they committed to a sprint backlog while they already knew it was not realistic?
Scrum, agile and lean are much used in professional work. More recently we have seen scrum and agile principles being applied outside of IT. In the past two decades especially within IT team. For instance, non-It scrum [NLS12], scrum in the church [Sut09], Scrum4Mom [Scrum4Mom], Eduscrum [EduScrum], and Personal Kanban [Ben11]. Probably I forgot some more. The principles and concepts behind it are general enough to apply this also at home.
By writing this blog I want to inspire you to apply agile/lean principles at home too.
I would like to introduce you to Master PO. Master PO comes from the land of the rising sun. There he runs a successful sushi-shop with many happy customers.
Many has he trained in the art of successful "PO-ness". As of today Master PO will share his wisdom and shenanigans with you too.
The secret to 3-digit productivity growth is simple; stay focussed on your goal. One thing that keeps us from staying focussed is context switching; picking up a task, then interrupting it for another task and the starting up the previous task. Context switching originates from different levels within the organization. If you can effectively manage and decrease context switching, you can achieve amazing results and save a lot of resources. In this post I will tell you how to best combat context switching and gain more focus.