The art of simplicity

One of the mantra’s I always preached for my teams was the concept of 'Continuous Improvement'. The idea is simple and appealing: we constantly seek incremental enhancements to our processes, products, and services. This approach, popularized by Japanese manufacturing methodologies like Kaizen, promises steady progress through small, ongoing adjustments rather than dramatic overhauls. However while reading the ‘Leadership is language’ by L. David Marquet, I started to wonder; what if this widely accepted wisdom is fundamentally flawed? What if true improvement doesn't actually happen continuously at all? The stairway, not the ramp In his book, David explains that improvement doesn't occur as a smooth, uninterrupted climb upward. Rather, it happens in distinct, intentional batches - like climbing stairs instead of walking up a ramp. This is what he calls "discontinuous improvement," and understanding this concept can transform how your team operates. ...

The Art of Agile development is one of the must reads if you take a leading role in any software team. In 2021 James Shore released an updated version of his book. To celebrate the one year existence of his book, James was so kind to make a dozen of the practices shared in the book available for free : Free Introductory Material: What is Agile? How to Be Agile Choose Your Agility Free Practices: Teamwork: Whole Team Team Room Planning: Stories Adaptive Planning Ownership: Task Planning Capacity Accountability: Stakeholder Trust Collaboration: Collective Code Ownership Development: Zero Friction Test-Driven Development ...

Microsoft transitioned from a large enterprise software business to a cloud company. In that sense, they are like most compagnies out there who struggle to move from an existing business model to a new cloud first service model. This also means that there are a lot of useful lessons that are relevant for all of us. Through the Microsoft Dojo for customers program, they started to show the way they work, the way they learn, and the way they experiment. Here are some of the topics they already covered: Dojo – People & Teams Dojo – Experiential Learning Dojo – Customers & Trust Dojo – Culture & Mindset Dojo – Product Centric Model – Part 1 Dojo – Product Centric Model – Part 2 Dojo – Product Centric Model – Part 3 Dojo – OKRs (Objectives and Key Results) Interested to learn more? Check out Microsoft Learn and start your DevOps Dojo journey .

As a developer or teach lead sooner or later you will be asked to estimate. Of course you could just throw out a ballpark figure but better is to use some historical data about your team performance. In that case I would recommend having a look at the online calculators and forecasting spreadsheets created by Focused Objective. They provide a lot of tools but also articles that can help you answer different questions about the current and future performance of your team.

One of the techniques that you see in bigger organizations that struggle to move to an Agile mindset, is the introduction of Release trains: A release train tries to align the vision, planning, and interdependencies of many teams by providing cross-team synchronization based on a common cadence. A release train focuses on fast, flexible flow at the level of a larger product. It is especially used in SAFe(Scaled Agile Framework) organizations. Their definition of a release train is: Agile Release Trains align teams to a shared business and technology mission. Each is a virtual organization (typically 50 – 125 people) that plans, commits, develops, and deploys together. ARTs are organized around the Enterprise’s significant Value Streams and exist solely to realize the promise of that value by building Solutions that deliver benefit to the end-user. Based on the definitions above you would think that a release train is something you should aim for, an end goal you shoul...

I could write a whole blog post about the resource utilization trap(and don’t get me started on the word ‘resource’) but I cannot explain it better as demonstrated in this brilliant video: A must watch for every (project) manager…

As part of your organizational transformation towards Agile you cannot leave a department behind. This means that the way your HR department works and handles things like recruitment, hiring but also compensation and benefits should change as well. Johanna Rothman shared a great set of posts about Agile HR: Creating Agile HR, Part 1: What HR Does Creating Agile HR, Part 2: A Flow for Agile Hiring Creating Agile HR, Part 3: Possible Agile Hiring Metrics Creating Agile HR, Part 4: Agile Sourcing Creating Agile HR, Part 5: Performance Management, the Career Ladder Creating Agile HR, Part 6: The Agile Compensation System Creating Agile HR, Part 7: Agile Feedback and Coaching Creating Agile HR, Part 8: Summary A must read for every HR manager…

Here is a great help in your Agile journey. DZone has grouped a lot of content to help you improve your inner Scrum Master . Here is the link: https://dzone.com/articles/stuff-every-agile-development-team-needs-to-know-a

In my job as a consultant I visit a lot of development teams. Most of them are using a ‘Scrum-like’ approach meaning that the typical Scrum ceremony(Daily Standups, Sprint reviews, Retrospectives,…) are in place. However I noticed that especially the Retrospective becomes boring after a while. To spice up your retrospectives and make them meaningfull again, I recommend having a look at http://www.funretrospectives.com/ . This site brings a lot of activies and ideas together for making agile retrospectives more engaging. Part of the information is also available as an e-book at http://www.caroli.org/book-fun-retrospectives/

In my continuous quest to spend my (too long) commute time in a useful matter, I discovered the following great podcast that focus on the social aspects of IT: Soft Skills Engineering podcast A show about the "everything else" in software engineering: team work, career planning, interpersonal skills, and more. Links: PocketCasts: http://pca.st/rnfV iTunes: https://itunes.apple.com/us/podcast/soft-skills-engineering/id1091341048?mt=2 …

A great read I can recommend for everyone interested in the Agile (r)evolution. It really focusses on the core concepts behind Agile and how to evolve from ‘doing Agile’ to ‘being Agile’.  From the website : Why do some companies excel with agile and others see virtually no improvement? The difference is culture and an understanding that agile is a framework for deep cultural change instead of a process or set of practices to increase efficiency. Processes and methods can become stale and rote, and can stifle innovation—even processes that were initially developed to be agile. An agile culture, however, will continuously improve and adapt without the need for periodic change initiatives. Why Agile Works: The Values Behind the Results focuses on why and how agile works and where agile should take organizations in terms of values. Here you’ll learn: - Why agile fails most often - How culture determines results - The difference between values and beliefs ...

As a consultant I spend a lot of time at different companies, giving me the opportunity to compare used practices, methodologies and tools. One of the things I noticed is that Agile has hit mainstream and is now applied almost everywhere. Most of the time, this means that companies are using Scrum or a derivative ScrumBut , WaterScrumFall ,… However, most companies make the same mistakes: Focussing too much on the Scrum ceremonies(Daily Scrum, Sprint Retrospective,…) without understanding the reasoning behind it Picking a subset of the Scrum concepts and ceremonies before first applying Scrum “from the book”, adapting the rules without knowing the importance of these rules Let’s use some Japanese wisdom and apply the Shu Ha Ri model of learning: This model shows the different stages that learners go through when learning new concepts: Shu—Follow rules to learn basics Ha—Break rules and discover context Ri—Mastery and find your own way If we apply this...

For most organizations releasing and deploying are the same thing while in fact these are 2 separate things: Deployment: A technical handling where a new version of the software is deployed to a specific environment Release: A business handling where the customers are informed that a new version of the software is available and can be used As you combine these 2 handlings in one, releasing becomes a risky business. The same moment you roll out the code on production, your users are eagerly waiting to start using these new features they so desperately needed.  At that moment, you don’t want that things go wrong. So what do most organizations do? They introduce long release cycles where an application has to go through multiple environments and test cycles before finally reaching production.And they try to reduce the risk by only going through this cycle one or 2 times a year. But while they are thinking that this limit the risk, it actually has an opposite effect. Th...

If I have to phrase the concept of ‘ DevOps ’ in one sentence, it’s: “Run what you wrote” I think that by making developers(and by larger extend) teams responsible for the code they wrote and the failures it caused in production, they learn to write code that doesn’t fail(and if it fails at least it does it in a graceful matter). Does this mean that developers get to do all the work and the system administrator can all take a long vacation? Of course not, it means that the concept of cross-functional teams, as promoted by Scrum and other Agile methodologies, should extend outside the analysis, design, development and testing domain and reach into operations. Only then, we can talk about truly cross-functional teams.

Although I have seen the power of a successful Scrum team, I don’t believe it’s the best fit in all situations . Scrum has a big impact on your (development) organization and requires buy-in at multiple levels to succeed. If you believe in the values and ideas behind the Agile Manifesto but think that Scrum will not work in your organization; or if you already tried Scrum and failed; I can recommend to have a look at Kanban. In my experience there is a lot less friction, especially if you are coming from a traditional Waterfall approach. Interested? Start by reading the following free chapter from the Agile Project Management with Kanban book: https://www.microsoftpressstore.com/articles/article.aspx?p=2316388 Of course, I can also recommend the full book: Agile Project Management with Kanban . Use Kanban to maximize efficiency, predictability, quality, and value With Kanban, every minute you spend on a software project can add value for customers. One book can h...

One of the signs of a good Agile team is that they have well defined ‘Definition of Done’. One thing that I learned over time is that you need multiple ‘Definitions of Done’ depending on the context(user story, release, sprint, and so on…). Mitch Lacey did a blog post where he shared his Team “Done” List : Daniel Gullo goes even further and split the Definition of Done in 2 parts: Completion Criteria and Acceptance Criteria: What are your ‘Definitions of Done’?

Agile became such a bloated term that it’s hard to define what it actually is. Chris Roberts created a one page snapshot view of all Agile values, principles and activities grouped into logical categories. Very useful!

Today, almost every customer I visit has jumped on the Agile train. They are working in ‘sprints’(with changing lengths), they do ‘daily standups’(but they only do it every week), they use user stories(but don’t talk to the customer), and so on… Does this mean that Agile is failing? I don’t know, I think you can still make it a success. How? Have a look at the following presentation by Mike CottMeyer for inspiration: Why Agile Is Failing in Large Enterprises, And What You Can Do About It from Mike Cottmeyer Also, don’t forget to checkout his blog: http://www.leadingagile.com/blog/ . Good stuff!

InfoQ offers a free ebook “Getting Value out of Agile Retrospectives - A Toolbox of Retrospective Exercises”. This pocket book contains many exercises that you can use to do retrospectives, supported with the “what” and “why” of retrospectives, the business value and benefits that they can bring you, and advice for introducing and improving retrospectives. Agile retrospectives are a great way to continuously improve your way of working. Getting actions out of a retrospective that are doable, and getting them done helps teams to learn and improve. We hope that this book helps you and your teams to do retrospectives effectively and efficiently to reflect upon your ways of working, and continuously improve them! Go download it PDF , ePub or MOBI format.

With the release of Update 1 for Team Foundation Server 2012 , Microsoft added a Kanban board to the list of available features. But where can I find this feature? If I click on View board in the ACTIVITIES list on the team home page, I end up at the original task board. Same thing if I click on the board menu option that appears on the Product Backlog page. So how can I open the Kanban board? On your team's home page, choose View backlog to navigate to the product backlog page. Highlight Product Backlog in the explorer pane and choose the board tab. The Kanban board opens.The Kanban board automatically displays the top-ranked items in backlog priority order. Column titles will vary based on your process template. What’s nice is that you can limit the WIP(Work-in-Progress) per column. More information at: http://msdn.microsoft.com/en-us/library/vstudio/jj838789.aspx#ViewKanban