Chemaclass - scrum

Agile Project Management

2023-05-31T00:00:00+00:00

A basic and straightforward overview of what Agile is, presenting some framework examples that are well known today, such as Scrum or Kanban, everything condensed in a 100’s pages book that you can read in a couple of hours.

Chapters

The fluid manifesto
Being agile
Agile process
Planning for success
Agile communication
Scrum basics
Introduction to Kanban
Building an adaptive team
Leadership and collaborative management
Common errors behind agile failure
Final words: agile is adaptation

“The benefits of Agile projects extend no only to the team using it, but also to the customer receiving the final product.”

“There is an underlying critical metric that consistently leads to the success of an Agile project: communication. Miscommunication, under-communication, or poor communication of any type leads to the collapse and failure of said project.”

Key takeaways

Projects that followed a Waterfall methodology tended to exceed their expenses over time, while the product delivered was below standard and difficult to use.

That situation originated that a group of developers signed a brief, 68-word manifesto in 2001.

A brief background

During the 1960s, software got into a big crisis; creating software was complex but changing it later became pure chaos. Waterfall to the rescue.

Waterfall outlined a simple, logical set of processes that a company would need to follow for a project to be successful. Its name comes from the metaphor of water gently cascading down a predictable, steady, incremental stream. Its life cycle of software development would be in six simple steps.

Requirements
Analysis
Design
Code
Testing
Operations

For 10 years, Waterfall was the standard methodology in the software universe. And for 10 more years, chaos persisted. Although the intention was good, the reality is that the ever-changing set of constraints does not cope very well with this methodology because each step is dependent on the previous one.

86% of the time a company uses the Waterfall method for project management, the customer receives inadequate or useless software. A lot of software projects were unused or never finished.

During the 70’ and 80’, Iterations and Incremental Development (IID) proved to be a viable option. In the 90’ surges an Evolutionary Delivery (ED), which changes the situation. The developer is responsible for listening to the user’s reactions early and often. The user starts playing a direct role in the development process.

A few years later, a new method surged Rapid Iterative Production Prototyping (RIPP), later called Rapid Application Development (RAD), which they claimed “Working software in 90 days… or your money back.”

Lastly, during the 90’ Extreme Programming (XP), Scrum, and Crystal were defined in detail.

These distinct yet similar solutions were decentralized, working independently of one another. This realization led to that night in Utag the unification of these ideas under one banner, in one document.

Agile became the definitive standard for software development.

The Agile Manifesto

Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan

That is, while there is value in the items on the rights, we value the items on the left more.

Ignoring Scrum to Get More Agile?

2022-12-06T00:00:00+00:00

Talking to a friend about agile, he asked me a fascinating question remarking how badly sometimes Agile and Scrum fit together, especially regarding meetings. These are my thoughts about this topic.

“Do you think it would make sense to just use agile and ignore scrum (sprints) completely in a product based development company. I feel it’s hard to be agile when you have 10 hours of meetings per week.” Filip G.

That is related to the essence core of Extreme Programming, which is the first value: Effective Communication.

“Probably some companies just don’t know how to properly use meetings and just have them out of habit.” Filip G.

I wouldn’t say completely ignore Scrum. Scrum (when done well) is a great “Product Management” Framework. To improve your understanding of Scrum I recommend reading: Scrum: The Art of Doing Twice the Work in Half the Time.

The main issue with scrum nowadays is that management took control over the whole thing, and developers are not really educated about how to practice Scrum properly (in a real Agile way), and that’s where the problem starts. For this, I recommend a book that addresses pretty well the common issues that most Scrum teams face in a fun and easy-reading book Zombie Scrum Survival Guide: A Journey to Recovery.

It’s not about Agile yes, and Scrum no. They are totally compatible. The issue is to create awareness about how to focus the team processes from an agile point of view.

Agile in a nutshell

I recently wrote a blog post about agile fundamentals, which I recommend you to read to get into the details: Working agile with non-agile teams. But, the tl;dr: Agile is about quick feedback. It’s about effective communication and reducing waste while aiming for simplicity.

Agile is about keeping these values always present:

Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan

While there is value in the items on the right, we value the items on the left more.

Scrum in a nutshell

Scrum is a framework for project management emphasizing software development, although it is used in other fields like sales, marketing, and more. It’s designed for teams of 5 to 9 people (see Dunbar number) who are totally autonomous and responsible for breaking down their work into small chunks that can be completed in a time-boxed iteration, called sprints, usually 1, 2, or 4 weeks.

It’s common to find certain ceremonies/meetings like:

Stand-up: 15 min (or less) to keep everyone in the team sync and updated about the work and call out for action when anyone is blocked or needs special attention or help.
Refinement: 2h? meeting to make sure the tickets are in a good shape before planning them to be worked on in the next sprint.
Planning: 2h? meeting to plan the work to be done in the next sprint.
Demo/Review: 2h? meeting to show the work done for the whole team, stakeholders and other interested people.
Retrospective: 2h? meeting intended to enable the team to reflect and improve.

The critical question is how your team organizes these meetings and, most important of all, how effective these are. These above are just some of the important meetings you have in any “Scrum Team” nowadays.

Still, apart from those, you might encounter a lot of additional meetings that pile up, and suddenly your entire working day is gone, and you feel you didn’t produce the value you expected. Unless your job is being in meetings every time, like coordinating projects and talking to people all the time, it seems something is wrong.

Boring meetings

Have you ever been in any of those meetings and thought, “This is boring, what a waste of time…”. Well, I’ve experienced that more than once. Who’s to blame? That would be the very first question that could come to your mind. Followed by, “My boss, obviously, because he/she organized that meeting, to which I got invited, therefore I am forced to attend, and this wasting time is their fault.”

This is a tricky question, and I don’t think it is an honest answer. However, there is an easy explanation for this answer: pushing away responsibilities and blaming others rather than yourself is way easier.

“I am forced to attend, and this wasting time is their fault” it could be that that’s actually the actual fact. You were really forced, and you’re wasting your time, and there is no other way… but is there no way to act on it, really?

When something doesn’t work the way I expect (e.g., I don’t like the outcome, or I think something is off), before blaming and pushing away responsibilities to others, I want to reflect on it and identify the root of the issue. What could I do to make the situation better?

What can you do about it?

Coming back to this context of “many meetings”, if you see yourself in a meeting again that feels off or boring, try asking yourself:

Am I feeling bored? Why so? Is it possible that I am not participating in the desired outcome of the meeting? And if so, is my presence here in this meeting really necessary? Could I simply ask for a summary afterward and jump outside the meeting to do something more productive?

Contrarily, is it OK to feel bored in this meeting? Or should I participate and engage with my peers to contribute to the outcome of the meeting?

In these situations, I encounter a pattern such as:

If the meeting is not boring, it is productive and will produce a rich outcome for you and, hopefully, all participants.
If the meeting is boring, then either A) it is OK to be boring, politely ask to leave, and you will get the summary afterward, or B) it is not OK to be boring. Your participation is necessary for the outcome of the meeting. Try being more engaging with your peers, and the meeting won’t be boring.

In the end, there are a lot of strategies, and it’s up to you to act on them whenever you see something that could be improved.

It’s OK to point out the “elephant in the room” and ask for help to improve any situation you think (or feel) is not working as it should.

Zombie Scrum Survival Guide

2021-03-01T00:00:00+00:00

I really enjoy the ideas and experiments presented in the book. It points out a lot of “big elephants in many rooms” for a lot of teams claiming to do Scrum or Agile in a really questionable way, aka: Zombie Scrum.

Summary

Zombie Scrum Survival Guide reveals why Scrum runs aground and shows how to supercharge your Scrum outcomes, while having a lot more fun along the way. Humorous, visual, and extremely relatable, it offers practical approaches, exercises, and tools for escaping Zombie Scrum. Even if you’re surrounded by skeptics, this book will be the antidote to help you build more of what users need, ship faster, improve more continuously, interact more successfully in any team, and feel a lot better about what you’re doing. Suddenly, one day soon, you’ll remember: that’s why we adopted Scrum in the first place!

Learn how Zombie Scrum infects you, why it spreads, and how to inoculate yourself.
Get closer to your stakeholders, and wake up to their understanding of value.
Discover why Zombie teams can’t learn, and what to do about it.
Clear away the specific obstacles to real continuous improvement.
Make self-managed teams real so people can behave like humans, not Zombies.

This is a nice webinar, when they offer a fresh perspective on Zombie Scrum, share key insights from the book, and discuss their latest findings on the relentless ongoing research.

Agile Product Management with Scrum

2021-02-22T00:00:00+00:00

Coverage includes

Understanding the product owner’s role
Envisioning the product
Grooming the product backlog
Planning the release
Collaborating in sprint meetings
Transitioning into product ownership

Scrum

2020-06-10T00:00:00+00:00

Every organisation, whatever its size, constantly has to come to grips with delivering a product or service on time and on budget. Scrum shows you how. It explains how to define precisely what it is that you are seeking to achieve, how to set up the team to achieve it, and how to monitor progress until the project is successfully completed.