First things first: what actually lies behind the idea of agile development?
We live in a world where people’s needs change hand in hand with constant arising challenges and developments of distinct nature. People’s needs become quite complex in their specifications. Accordingly, products and services have to rapidly evolve in order to meet their clients’ will.
Everything in software changes. The requirements change. The design changes. The business changes. The technology changes. The team changes. The team members change. The problem won’t be change, because change is going to happen; the problem, rather, might be our inability to cope with change. This fact challenges the ability of organizations of any kind to ensure satisfaction of both exigent customers and employees responsible for the production.
In this context, speed and flexibility are both desired and reputable organizational characteristics. With this background, agile methodologies like Scrum are more and more favored worldwide in different business areas and other types of organizations. Frameworks such as Scrum aim to bring complementary team players together. These individuals are expected to take action as a cross-functional unit and work in an iterative way when striving for a goal.
The art of getting twice the things done in half the time is what makes Scrum attractive!
You might wonder, what exactly actually makes Scrum that attractive? And the answer is that if Scrum teams apply Scrum and improve it continuously, the team could in one of its best stages get twice the things done in half the time. This has been proven to work. Yet, if you have your doubts, I recommend a small research about SPOTIFY or TESLA, just to mention some successful agile practitioners.
In my position as a Scrum Master at ePages I need my teams to “land their projects” as often as possible. One of these teams lands their project every two weeks. That is, they have two-week sprints where they set themselves a goal and “land” once they get the goal done.
About continuous learning
I see my mission as a Scrum Master in fostering continuous improvement. That means that my team should constantly identify what can be improved and find, with my help, a concrete way to do so.
All this probably sounds too abstract, almost philosophical for some of you. For this reason, as follows, I want to offer a concrete example of how the team improved on the fly one element of their implementation of Scrum and filled it with a self–defined process:
Defining the team’s Definition of Done
Many of you might know that Definition of Done is a set of fixed criteria we apply to all user stories in a product. Think of it as a quality mark when shipping the completed stories. The good Agile uses Definition of Done to drive performance, quality, and accomplish the design goal of Scrum: hyper productivity!
After various sprints together as a new team, some members noticed, for example, that what one understood under QA was not necessarily what the other understood. Is was becoming usual to think a task was finished and still end up missing the expectations of teammates or the Product Owner related to one or the other quality criteria. After all those hours in front of the computer: upsetting and frustrating, right!?
On the bright side, we learnt that if the team shares a sprint goal every two weeks, it makes sense that all the team folks have a joint understanding. That means, which steps must be followed and which criteria must be fulfilled for each story, to guarantee the quality defined by the team itself.
You should simply be able to rubber-stamp each story as having met a master set of standards. My team dedicated one hour to write a Definition of Done (DoD). I offered the team an explanation of what a DoD is good for and gave them some hints as in what to pay attention to. Every team member had the chance to individually collect the elements they would include in their definition of done:
Later on, we did some magic out of our conversation skills and … Eventually, the team agreed on the following flow and I visualized the new team agreement in our room, in our Confluence space and on our screen. See the mega cool result, which of course should be revised whenever needed.
If you want to get things Done-Done as a team, agree first on what Done takes. Apart from that, DONE is a pure matter of effort.
About the author
