The shift left fallacy
I am done with the whole shift left storyline.Read more →
I am done with the whole shift left storyline.Read more →
Talking about the added value of applying Agile Architecture in your organization, we see fewer and fewer “IT architects” in organizations. Is that because we do not need Architects anymore?Read more →
During the lockdown, we do Planning Poker in Zoom or Teams. Which tool can you use the best to collaboratively determine our estimates? Which facilitates the best interaction in your Scrum team?
You’d like to keep doing this, because this Refinement practice naturally raises:
1. The team’s awareness of what work is expected and get clarification.
2. Knowledge and tactics will be shared
3. Assumptions will become clear
4. Negotiation with the Product Owner will occur to keep it small AND valuable
More about why estimates work: Read this book Agile Estimating and Planning by Mike Cohn.
What’s the best Planning Poker tool would you use in Zoom or Teams? I had a discussion with my Agile coach colleagues within Xebia. We agree analog cards trumps any online tool. Why?
A. First, analog cards are easily made available to anyone. So, no firewall to jump over. And no licenses needed. No security compliance issue. Just create them!
B. Secondly, each team member could create the card deck themselves. As a consequence this fosters ownership. Some will introduce some fun and/or improvement. Especially, if you encourage any team member, to introduce an extra card. For example, ‘time for a break’ or ‘we try to estimate too soon’.
C. Most importantly, it will naturally enforces any team member to put the camera on. Raising opportunities to spot non-verbal signals of anyone. That’s great!
This together comes close to mirror the office situation. And as an advantage, the screen sharer doesn’t need to switch applications all the time.
See my deck of cards. Easily made of some thick paper and a fat black marker, for instance.
You can use these planning Poker cards in any Zoom or Teams meeting. A low-tech solution facilitating great interaction!
Any questions? Raise them below!
Would you like to become the best Scrum Master? Join our Advanced Online class
Would you like to deepen your tactics in great Refinement? Join classes like
Specification by example by Gojko Adzic It is the cornerstone of any successful requirements and testing strategy with Agile and Lean processes, like Scrum, Extreme Programming, and Kanban. This workshop teaches you how to apply SBE to bridge the communication gap between stakeholders and implementation teams, build quality into software from the start, design, develop, and deliver systems fit for purpose.
Make your team stronger. Distribute the workload of testers among time better and become better as a team? Understanding cross functional competences and needs will increase while applying Test Driven Development.
Agile teams often use the concept of personas to create more tailored user stories, so could you use evil personas to describe malicious behavior?
Personas are “synthetic biographies of fictitious users of the future product” and “a powerful technique to describe the users and customers of a product in order to make the right product decisions“. The purpose of using personas is to “understand who the beneficiaries of the product are and what the goals they pursue”.
In essence, personas help teams understand if the designed functionality actually fits the end-user desires. This makes it a powerful approach to also identify possible risks by introducing malicious users or ‘evil personas’.Read more →
Security is about making risks visible and mitigating the impact of possible incidents to an acceptable level. The ‘security by design’ philosophy aims for every application or system to be at an acceptable risk level, all the time.
When starting with a ‘secure by design’ approach, often existing security processes are simply bolted onto the development life-cycle. One of the major pitfalls of this approach is requiring teams to do a YAPWAV. YAPWAV stand for the developer’s hell called: Yet Another Process Without Added Value. A YAPWAV is an activity a team solely has to do to please a stakeholder, without noticeably improving the product they’re building.
A classic example of a YAPWAV is the mandatory risk assessment for each software deployment, just for the purpose of satisfying a documentation process. These kinds of security processes are bound to fail as they add no (visible) value to the product the team is building. In the agile philosophy, every action or activity should contribute to the value of the product. The moment an activity is introduced that doesn’t add visible value, teams will decide it’s not worth the effort and stop doing it.
Welcome to my second blog in the series of five quality patterns in Agile development that can help you to deliver the right software with great quality. In my previous blog, I’ve introduced Example Mapping as a method to get to specific examples for scenarios or rules that your user story is made up of. The output of the refinement sessions are your requirements and thus your tests. In this blog, we will take a further look at these test cases and why it is important to automate these acceptance tests. Not just from a development team perspective, but also what they can bring to your business.Read more →
Are you worried your new project won’t be successful? Or afraid getting stuck applying these new techniques you just learned in a training? Or are you perhaps part of a very pro-active organization, but is a lack of focus crushing all new initiatives in the long run?
At Xebia we help customers as consultants, but also as facilitators or as trainers. A common pattern we see is people worry about how to move forward with their newly acquired knowledge or insights. In order to improve your chances of success, it can be very useful to do an upfront analysis of the causes of these worries. This will help you steer clear of the rocks, and prevent early ship wreckage of your new ideas. One of the formats we’ve been using over the years is the so-called Pre-mortem.
There are several recurring wishes our clients bring to us, one of which is speed, to improve time to market. However, there is no dial that we can turn to deliver value faster. Software teams are not like cars; there’s no accelerator pedal. Even if we try to speed up by adding more resources, in many cases, the actual bottleneck will just become more apparent.
In our search for increased delivery of value, we hunt for these bottlenecks. No two contexts are the same, and for this story, we have a particular context in mind. Symptoms in different organizations are often similar, and our story might apply to your setting if you recognize the problems we encountered.
The Sprint Review is generally the hardest event to get right. It’s where the Scrum Team and their stakeholders meet, thus the event with the largest number of participants. It’s also the event in which different people come with a different purpose.
One thing I’ve observed is that the focus is often on What was planned and What is now “Done”. I feel this is an anti-pattern. While progress is important, I feel the focus should be on What is “Done” and What to do next.
Multi Products Scrum teams are in reality observed often. One team serving different stakeholders and customer segments. Both would like to use the same people to work on their improvements.
In most organizations there tend to be more products than teams. While scaling frameworks give solutions on how to cope with a big Product and orchestrating value delivery among multiple teams. But how to deal with many products and a few Scrum teams?