Agile and Scrum Blog – All about Agile and Scrum by Zuzi Sochova, Agile...+Add.Feed Info1000FOLLOWERS
I help companies and individuals to be more successful.
Teaching teams and their managers how to be more efficient, how to provide better quality and how to communicate and organize teams so that people have fun, they are motivated and have high commitment. I support them in changing their traditional processes to Agile, or implementing Scrum and Kanban.
The world is changing in cycles, fashion goes in cycles, and the same is true for Agile. What was trendy yesterday, is not today and it can change surprisingly fast J So let’s have a look what are the new trends in Agile and what the Agile community is talking about:
Agile Leadership and Agile Organization
Agile is not just a set of practices how to write a good software, but it’s more and more used in every part of the organization. The traditional leadership (leader-follower model) is no longer acceptable in Agile environments. In the previous years, almost everybody focused on teams and how to adopt Agile, Scrum, and Kanban to the teams. But if we want to be successful at the organizational level, this is not enough. We need to push boundaries and help the whole organization to change. Hand in hand with that, we need to grow Agile leaders and support Agile leadership which is the critical key to the organizational success with Agile.
Agile out of IT
As it was already mentioned, for real success, it’s important to change the whole organization into Agile. The common practice is to change IT department and leave it as isolated island inside the traditional organization. But this is just the beginning. The company has to follow the same culture and the same style of the working, so you hear more and more about Agile in HR and talent management, Agile finances, Agile marketing etc.
Finally, there is a term of Business Agility which brings back the real value of Agile. Agile was never meant to be development process of your IT. It was supposed to be business value driven. It should bring the startup mindset back to the organizations, and look at the delivery from a business perspective. Prioritize, deliver value in short cycles, get feedback, measure impact. This is the real Agile mindset.
If you are in Agile or do you plan to try and implement it focus on these topics because without it Agile become only an empty skeleton of practices and processes. Agile is organizational change, it changes the mindset, culture, leadership, and business focus. If you take it as such change, you are going to be successful with Agile.
In order to achieve success at the organizational level, we need to start management talent development program to create leaders who will help to grow a company, make quick decisions and stay ahead of others. Modern leadership style is no longer applying the traditional model of the “leader-follower”, i.e. one decides and the other executes orders. Nowadays, when most employees are from the category of creative workers and the company is looking for innovation and creative ideas to stay competitive, the leader-leader model is a more effective one, where the leaders’ main goal is to help others to be successful leaders. What is modern Agile management or Agile leadership about?
Excellent Agile Leader has four core competencies: Ability to define the vision, motivate, gain feedback, and ability to influence through themselves, others and system.
The ability to formulate a vision is the engine of change and motivation. A vision is not necessarily linked to product and business but should be focused on the organization and its purpose. The second competency is the ability to motivate and give the energy. It is a competence closely related to the vision. If you have a good vision, it motivates itself. Agile leadership builds on so-called internal motivation to strengthen the autonomy of individuals and teams. The third of Agile leader’s competences is feedback. Feedback is DNA component for Agile Organization together with openness and transparency. The art of getting system-level feedback is critical for the leader. The last is the art of influencing complex environments. Change things, people and their behavior, support and consolidate culture. Agile leadership begins with a change of self, your judgments, values, and behavior, style of work. Great leaders start with themselves as a role model, to change the way they show up, how they interact with others, and how they can inspire people around them to collaborate, create a team spirit, and become leaders. They are capable of working with the entire system and influence the whole organization and its culture.
Agile Leader Wheel also defines four supporting competencies to help leaders define the right approach. When is it better to decide and when decisions can be delegated and it’s better to collaborate. At the same time, when it’s better to take a role of facilitator and when start coaching. We do not talk that much about coaching individuals, which of course may be useful, but coaching the whole system – teams and organizations as a whole. Excellent Agile Leaders have not been born as Agile Leaders, but they are constantly looking for new ways to get better and to gain and strengthen the above-mentioned competencies.
#1: Big Apple Scrum Day (New York, NY, USA) – May 11, 2018. Enthusiastic community, great space.
#2: Agile Prague Conference (Prague, Czech Republic) – September 10-11, 2018. An awesome program, collaborative atmosphere of open space format, good value for money.
#3: Business Agility 2018 Conference (New York, USA) March 14-15 2018. This conference has the most innovative format of all Agile conferences – three short industry experts’ talks are followed by facilitated conversation around tables.
#4: ACE! (Krakow, Poland) – May 17-18, 2018. Innovative form & great atmosphere.
#5: Agile Austria Conference 2018 (Graz, Austria) – May 17-18, 2018. Great place to meet & join Scrum Alliance DACH chapter – one of the most active Scrum communities.
#6: AgileEE (Kiev, Ukraine) – April 27-28, 2018. Interesting speakers and nice audience.
A few days back there was a new update to the Scrum Guide – the definition of Scrum. So what’s new? Not much, which is a good think. Most of the changes were minor, correcting, clarifying and updating the text so it’s clearer. Few interesting updates:
The trend of using Agile and Scrum out of IT was addressed explicitly:
“Scrum has been used to develop software, hardware, embedded software, networks of interacting function, autonomous vehicles, schools, government, marketing, managing the operation of organizations and almost everything we use in our daily lives, as individuals and societies.”
Nothing new, for us, but it can make a difference to the people new to Scrum.
I specifically like the update in the Daily Scrum section where the three questions were only made as one option. Finally, right.
“The structure of the meeting is set by the Development Team and can be conducted in different ways if it focuses on progress toward the Sprint Goal. Some Development Teams will use questions, some will be more discussion based.”
So there is a chance people stop using it as individual status meeting and use it to inspect and adapt their plan ow they are going to achieve the Sprint Goal.
The only change I don’t understand as it is to my opinion going against the philosophy of Scrum as a framework, not a process is the Sprint Backlog section:
“To ensure continuous improvement, it (Sprint Backlog) includes at least one high priority way in which the team works, identified in the previous Retrospective meeting.”
So here we are, pushing one practice which may be good for the teams who are at the beginning of their Agile journey and don’t improve as part of their DNA to everyone. I can imagine many other ways how to improve then making it part of Sprint Backlog and soften the line between delivering value and “other important tasks which need to be done”.
I like Scrum as it is not much prescriptive and I hope such weird changes will not increase as they will eventually be the end of Scrum as a flexible framework…
Some time ago, when I first heard the definition of LeSS (Large-Scale Scrum) product, I found it a bit unrealistic. Large-Scale Scrum is one of the Agile Scaling methods and I happen to like it as it’s very close to what I had experienced to be successful in various environments before. But the definition of the product is quite wide. Specifically – the product shall be as wide as possible, but still practical. If the customer feels it’s the same product or if it’s similar from technical perspective, it is the same product. When you start to apply this rule, in general it means that most of the companies have one product only.
Let me give you a few examples… Amazon and all its services shall be one product because that is how customers see it, the service company delivering internet solutions and mobile apps for variety of the customers is one product despite of the diversity of the customers and technology, the maintenance and the new development is one product as it is same from the technical perspective. Your projects are just Epics in your Product Backlog. When you think about it for a while it makes sense, as you need consistency in your delivered functionalities, flexibility to be business driven and ability to prioritize your business only by business value not by technical skills or domains. This is the real crossfunctionality we aim for. It’s not that difficult despite of the complexity of your product. The people who create our software are usually having university degree which shows they can learn. They are smart and creative software engineers. They can make it. If you do it this way it makes everything so much easier as dependencies at code level are much simpler than dependencies at business level.
Definition of Done (DoD) is a simple thing, although people are often struggling with it. It only defines what “done” means. It brings consistency into the product delivery. It sets the bar of quality we all keep the same. People often mix it with the acceptance criteria and are confused. So let me summarize it. Definition of Done shall be the same for all Product Backlog Items, as we need consistency, we need to know which quality standards are kept. Definition of Done is created as an agreement between Product Owner and Development Team, so it contains both technical and business quality requirements. It shall be stable for the product and not change Sprint to Sprint. Eventually, we can improve it, but we aim for consistency so we keep it stable. Definition of Done is the same for all teams who work on the Product Backlog to keep that consistency.
So how can such Definition of done look?
Running on test server
Accepted by Product Owner
You can make it more specific:
Coded according to Product Backlog Item (User Story) definition
Automated tests (unit, functional)
Reviewed (by different team member)
Running on test server
Accepted by Product Owner
Eventually, in some time we may improve it for example as follows:
Translated to Chinese, French and German
Running on production
Contains business measures how users used it
Accepted by Product Owner
In this case, we achieved continuous delivery within our Sprint. We release each Backlog item to our users directly whenever it’s done. We need to translate it as a part of that otherwise we can’t be able to release. And we have to add some business measures to know if we are getting the expected impact or not and get fast feedback. As you might see, the more the organization is Agile and teams cross-functional, the wider is their Definition of Done.
Definition of Done shall be visible so everybody can see it. Never compromise. The User Story is either done or not. Any other state only brings chaos and makes any release completely unpredictable.
Are we already Agile? How do we know we are Agile? What level of Agility have we? It’s hard to say. On one hand, you never touch Agile as Agile is like a star on the horizon. On the other hand, you can feel it after the first 15 min you enter the organization from the energy, level of the positivity, interactions from people, and company space setup. A bit later you might search for more tangible proofs of Agility / non-Agility. But the initial sense if usually right.
It’s so hard to measure as once some authority publish the assessment questions, companies make those things happen and fake it. It will most likely not even be conscious, as people are starving for simple recipes. So such assessment can only work once in life. Here are the first seven ideas which come to my mind. If you like to answer, be honest and use the whole scale <0 .. 10>. No organization is ideal, and so there is low chance you will be the ideal one.
I can continue, but firstly people can only answer few questions, I hope 7 is not too much and secondly, it’s just a short test which is only valid for the first time you do it, next time when we meet during my Agile coaching, I will ask a different set of random questions :). It’s not any complete assessment, just a fun test which can possibly make you think about yourself and your way of work.
If I got enough replies, I will publish them in some of the future posts.
Read Full Article
Scroll to Top
Separate tags by commas
To access this feature, please upgrade your account.