For KnowledgeHut I have written an article explaining the role of Scrum Master, and the value of a certification.
You can read the article here:
For KnowledgeHut I have written an article explaining the role of Scrum Master, and the value of a certification.
You can read the article here:
For KnowledgeHut I have written an article explaining and comparing Certified Scrum Master (by Scrum Alliance) and Professional Scrum Master (by Scrum.org)
You can read the article on this page: https://www.knowledgehut.com/blog/agile/csm-or-psm-which-certificate-is-more-valuable
Over the past decade, innovative companies, software industry thought leaders and lean/agile pioneers have discovered simpler, sturdier, more streamlined ways to be agile. These modern approaches share a focus on producing exceptional outcomes and growing an outstanding culture. Today, it makes far more sense to bypass antiquated agility in favor of modern approaches.
World famous organizations like Google, Amazon, AirBnB, Etsy and others are living proof of the power of these four principles. However, you don’t need to be a name brand company to leverage modern agile wisdom.
“Modern Agile is a community for people interested in uncovering better ways of getting awesome results. It leverages wisdom from many industries, is principle driven and framework free.”
— Joshua Kerievsky, CEO, Industrial Logic.
Modern agile is the result of courage, feedback, simplicity, communication, and respect for people.
Modern Agile has 4 guiding principles:
These principles unfold (expand) in many practices! These are not only applicable to software development.
Joshua is the founder and CEO of Industrial Logic, a pioneering Extreme Programming/Lean consultancy that radically improves the software development capabilities of organizations around the globe.
In the mid-1990s, Joshua was among a small community of “lightweight methods” practitioners experimenting with better ways of developing software. Since then, he’s helped thousands of people across hundreds of organizations learn better ways of making software, carefully reviewing and revising methods with the greatest impact and return on investment. Today, he leads an effort to modernize Agile by removing outdated practices and leveraging the best of what the software community and other industries have learned about achieving awesome results. Modern agile practitioners work to Make People Awesome, Make Safety A Prerequisite, Experiment & Learn Rapidly and Deliver Value Continuously.
Joshua is an international speaker and author of the best-selling, Jolt Cola-award-winning book, Refactoring to Patterns, numerous Agile eLearning courses, and popular articles like Anzeneering, Sufficient Design and Stop Using Story Points.
–> keynote talks by Joshua Kerievsky
–> Podcast with Joshua Kerievsky: http://agileuprising.libsyn.com/joshua-kerievsky-modern-agile
I’ve stumble upon this list, and I like it – as it clarifies again a bit the role of the Scrum Master.
The most important objective of a sprint in Scrum is to deliver a product increment – a piece of working software delivering value for the end-user. That is the goal today, and always has been the goal.
In a context, in which multiple Scrum teams work on the same product, it’s the goal – and only goal – to deliver each (and every) sprint an product increment – so no UNDONE work left at the end of the sprint.
Scrum does not define what “done” means for a product – that’s to be defined by the development team.
Yet the goal is to get better and raise the bar, in order to be able to deliver a piece of valuable working software at the end of each sprint.
With support of the Scrum Master, the development team improves their practices at a steady pace to be able to reach that goal.
The Scrum Guide says:
“As Scrum Teams mature, it is expected that their definitions of “Done” will expand to include more stringent criteria for higher quality. Any one product or system should have a definition of “Done” that is a standard for any work done on it.”
Unfortunately, we observe that many Scrum teams (or teams saying to practice Scrum) are not able to deliver a done product increment at the end of each sprint. In the world of software development, this means a piece of working software (end to end) ready to be used by a customer (end-user). Some teams simply do not care and finish the work till done at a next sprint.
The output at the of the sprint has been called a potentially product increment. Some teams interpreted this as “the product increment is ready to be shipped, but actually there’s still some work to do to actually release it to the customer“. That’s obviously not the point.
That’s why the Scrum Guide says:
“The Development Team consists of professionals who do the work of delivering a potentially Increment of “Done” product at the end of each Sprint.”
Jeff Sutherland and Ken Schwaber, – the creators of Scrum have been updated the Scrum guide over time. It’s interesting to read how in previous versions of the Scrum guide there was more detail about what done actually means, and what to do with “undone” work. The reason in general that some artefact and details have been left out, is to make the description of Scrum as a framework more simple, clear to understand and lightweight.
A completely “done” increment includes all of the analysis, design, refactoring, programming, documentation and testing for the increment and all Product Backlog items in the increment. Testing includes unit, system, user, and regression testing, as well as non-functional tests such as performance, stability, security, and integration. Done includes any internationalization.
You clearly get the picture, that “done” includes all the work necessary to be able to have a piece of releasable, valuable software at the end of the sprint.
“Undone” work is often accumulated in a Product Backlog item called “Undone Work” or “Implementation Work.”
Sprint by Sprint, the “undone” work of each increment is accumulated and must be addressed prior to releasing the product. This work is accumulated linearly although it actually has some sort of exponential accumulation that is dependent on each organization’s characteristics. Release Sprints are added to the end of any release to complete this “undone” work. The number of Sprints is unpredictable to the degree that the accumulation of “undone” work is not linear.
Take care, the current Scrum Guide does not specify a “release sprint” as a practice. This is similar to the “hardening” sprint defined in – for example – the Scaled Agile Framework. In Scrum, this is considered a bad practice. As stated the goal – and only goal is to create a done product increment at the end of each sprint. “Undone” work piles up and increases risks and delays.
The word “undone” is not mentioned anymore in the current version of the Scrum Guide.
Large-Scale Scrum (LeSS) (by Craig Larman and Bas Vodde) do explicitly mention “undone” work – in larger organisations there are often whole teams (e.g. an “operations” team, a “services” team) or whole departments (“operations” departement) or people (“release manager”) existing which are to be considered part of “undone” work if this cannot be done as part of the sprint (and it often cannot be done within a sprint).
A perfect definition of “done” implies that each product increment is
And that should be the goal of perfection.
To be able to achieve this as a team, effort is necessary to invest in:
without sound technical practices it’s fairly impossible to achieve this on any scale (small or large).
Do not make a mistake, this is quite a challenge for many teams who (try to) practice Scrum.
All variants on Scrum who do not achieve the actual state of “done” product increments, according to the rules stipulated in the Scrum guide, are not to be considered Scrum teams.
I quote this from – Ken Schwaber – and any software development team should adhere to these (working in Scrum or not)
The end result should include software that has:
It has these characteristics:
Source: Quality, Done Increment
Keep on improving!
And I don’t intend to say that with a negative perspective.
Quite often people wonder why Scrum – a framework for complex product development – has the rules as described in the Scrum Guide. The authors of Scrum (Ken Schwaber and Jeff Sutherland) say that the framework contains the roles, events, artifacts, and the rules that bind them together necessary to operate. Adding, changing or removing something will not make it Scrum anymore and a Scrum team will not work optimally.
Quote by Ken Schwaber:
“Scrum is a general-purpose framework applicable in complex situations, where more is unknown about the parameters than is known. The rules of empiricism and self-organizing make it work within short iterations that control the risk and increase chances of finding answers and creating value. The few roles, artifacts and events are fixed so the Scrum team can focus on unraveling complexity.”
What’s your opinion?
I came across an interesting article on InfoQ, it’s titled “Transforming from Projects to Products“. If you want deeper understanding on topics, InfoQ offers descent and great articles. So I’d like you (someone in any position who plans or is part of an “agile transformation” to read this).
Excerpts of the article:
” ‘Agile’ as we have come to know it whether we mean Scrum, Kanban, Lean, Lean Start-up, or any of the many other Agile frameworks is, in most cases a collection of historic good practices and guidelines identified by successful leaders and businesses in the past, they have been collected under one umbrella polished up a bit and marketed – very successfully – which is likely why you are reading this. I say this to discourage the notion that ‘Agile’ is new and untested, there are certainly some misinterpretations and misapplications but the underlying principles are sound and based on a lot of experience.”
In fact, each company or organisations should be concerned to become more agile (as defined in the dictionary), this is a matter of sound principles and ‘common sense‘ (for example: eliminate waste and become more effective in what you do – certainly in software development / product delivery there are many ways to achieve this).
Organisations shouldn’t embark on a mission to become agile, without understanding what it takes in terms of cultural and organisational changes – and most importantly: figure out what they want to achieve – why do you need a change?
Questions to be asked:
As you notice these questions which concern the whole organisation. Any initiative for improvement should be looked at globally – at an organisational (systems) level – in order to avoid local optimisations.
“Agile Product Leadership is about accepting the plan is likely wrong or at the very least unclear and the scope is unknown, and so adapting to change and building the right things to fulfil our customers’ needs.”
“What will I do today?” to “What can I do to help the team towards our goal today?”
can make a huge difference to behaviour.
“Your business should be saying:
Agile transformation may be a means of reaching that goal.
“If you choose an Agile Transformation you will measure success by delivering what customers need, by creating happy and satisfied customers not adherence to a plan. You will measure teams success by those that are willing to learn and grow. By empowering teams to make decisions for themselves you can create an environment of continuous improvement.”
Image source: https://quickscrum.com/Images/article_detail/Whyagiletransformationisdifficult-1.png
Podcasts are a great way to learn and to listen in to conversations with people you’ve might have heard of, but you don’t really know who they are. Podcasts are a tremendous source to learn about new topics – virtually anything!
I’ve been listening to podcasts for a while, mainly topics relevant to my professional occupation – but there are many many podcasts out there! I listen to podcast when commuting to work, on public transport or you can connect your mobile phone using bluetooth to your car audio system. At home in the evening, I can enjoy listening to a podcast (or an audiobook) – it’s a different experience than reading a book or blog – and I find it more relaxing.
Host: Vasco Duarte
Format: short episodes (10-15 minutes), from time to time a special longer episode
Content: Interviewing Scrum Masters world-wide
Why I like it: Vasco is a a great interviewer, the podcast has a clear structure, and Vasco is knowledge able on the topic – in other words, he can place questions and answers, he can put items discussed in a larger context. You hear real-world experiences of Scrum Masters. One remark: I do sometimes skip certain episodes if the interviewee doesn’t speak English good enough 🙂
The podcast has a fixed format: each week a Scrum Master is interviewed. Each day of the week, the Scrum Master interviewed is asked a question.
And some Belgian have been interviewed too! (Gunther Verheyen, Yves Hanoulle)
Host: Ryan Ripley
Format: mostly panel discussions, sometimes interviews with a specific interview during a conference. Episode length around 1 hour average.
Why I like it: these podcasts are recordings of informal chats and panel discussions, with people like Tim Ottinger, Zach Bonaker, Amitai Schleier. By listening you can follow their thoughts process, hear pro’s and con’s and challenge their thinking with your own thinking.
Host(s): Ryan Lockard, Andy Cleff and others.
Format: panel discussions, interviews
Why I like it:
Listen to the Manifesto Author Review. (currently 14 out of 17 of the original signatories have been interviewed)
I can highly recommend the episodes of the manifesto author interviews – the set of questions are largely the same for all interviewees:
Agile Uprising List of episodes
Why don’t you read and understand the Scrum guide?
Great article on why approaches like Scrum and Lean startup are about innovation, and change the culture of an organisation towards innovation. The author advocates that Lean/Agile coaching should be mostly change management. It should be about creating a culture of continuous innovation. I couldn’t agree more!
… if this explosion of Agile Coaches and Scrum Masters isn’t leading to a whole host of Scrum zombies, which will then lead to the conclusion in three years’ time that Scrum was a bit like drinking orange juice from jam jars: silly hipster shit. The emperor’s new clothes. Because nothing will actually have changed.
Image source: http://blog.agilistic.nl/content/images/2016/06/Zombie-Scrum—Johannes-en-Christiaan-1.jpg
“A good Scrum Master helps the team to solve their problems, helps them to reach the sprint goal.”
“A great Scrum Master helps the team to solve the most crucial problems, creates an environment for the emerge of new practices and emerging knowledge.”
Source: A Scrum Master’s Practical Toolbox
For the readers: A reference for organising retrospectives is the book “Agile Retrospectives – Making Good teams Great”, by Esther Derby & Diana Larsen. They describe the main steps of an agile retrospective.
The prime directive of retrospectives has been formulated by Norman Kerth in his book “Project Retrospectives: A Handbook for Team Reviews”.
“Regardless of what we discover, we understand and truly believe that everyone did the best job they could, given what they knew at the time, their skills and abilities, the resources available, and the situation at hand.”
You can find online all kinds and sorts of formats (games) for retrospectives; I’ve found back a description of a ‘base’ agile retrospective, and I’d like to recommend this to anyone. It focuses on what went well, what could better, and next on identifying and committing to action points for improvement.
What are your thoughts about retrospective facilitation techniques?
Reference to post: “Challenging Sprint Retrospectives“
There are many manifestos written, principles and values.
I sympathise a lot with this:
Imagine… everyone able to work consistently at their best:
Source: A True North for Lean-Agile?
Persoonlijke principes Continue reading →