Tips, Expertise, Articles and Advice from the Pro's for Your Website or Blog to Succeed
Much of the software development world has adopted new methodologies, such as agile, that enable them to deliver changes and updates to critical systems more quickly and efficiently.
In this 2-part blog series, I explain what agile development is and how it helps deliver software faster and then explore how you can implement this approach in SAP.
Since way before the time of the pandemic and the start of the most chaotic time ever for businesses, project management software has been very important for the organizational paradigm. They bring order and stability to the very chaotic project development process.
Knowing the importance of project management software is one thing but to have an idea about the best project management software in the world is a completely different animal.
There are great Scrum Masters and lousy Scrum Masters. There are also great and lousy managers, developers, testers, salespeople, and neighbors. People are people – no matter what their profession or role in life. Scrum Masters are people too. Like every profession, most people grow and improve with time and experience. Some grow more quickly than others.
Do you have obstacles (impediments) that continue to plague your team because the Scrum Master has not removed them? Or, is communication inside the team or external to the team poor and hampering your ability to get things done? Perhaps you feel like your team is stuck in a rut and your Scrum Master doesn’t seem to be doing anything about it. What do you do if your Scrum Master isn’t all you hoped they would be?
One of the twelve principles behind the Agile Manifesto says: “At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly”. Agile is all about adjustments here and there, learning, fine-tuning and responding to change.
It’s really hard to adjust and fine-tune effectively if we don’t pause to find out where adjustments are needed. The Sprint Retrospective is the mechanism that Scrum teams usually use to fulfill this principle of inspection and adaptation. Unfortunately, the retrospective is often treated like an add-on or a luxury and performed only “if there’s time”.
You may also like: Agile Project Managements Explained — A Beginner's Guide
Agile can offer faster, more flexible development for your SAP environments. With so many methodologies for agile, how do you know which one will be the best fit for your business?
I spoke to a large SAP enterprise recently about their shift from a waterfall development approach to using agile development in their SAP environment. The result was that rather than making two changes to SAP each year, they now modify their environment each and every week.
“At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly” — The Agile Manifesto
A few weeks ago we considered the Agile Manifesto from a lean perspective. We saw that it is possible to map the 12 agile principles to the seven canonical “Lean Wastes” in terms of a mitigation approach. Although it is not an exact science, the act of going through such an exercise may be useful. It can help us to improve our appreciation of how lean and agile practice relates to each other through their shared philosophical underpinnings.
Kanban is awesome but it has to be managed well. Let’s have a look at how to implement an effective Kanban system to make your projects easy to manage.
As fast as the digital world is changing, so are the jobs. The jobs that were in great demand a decade ago are almost non-existent now. This holds true for every industry, including project management. In order to lead the team in the right direction, a qualified and a skillful project manager is a must.
A project manager is someone who acts as a glue and keeps things together, which is why it's important to work towards becoming an effective one.
We've all seen it: The Scrum Team goes through the motions, implements all the mechanics of Scrum, and still when we look at what's going on, it doesn't feel right.
Steve Porter fondly named it Believably Bad Scrum. I call it Scrum Theater. Barry and Christian call it Zombie Scrum.
Today, it’s pretty normal to write new applications in a “cloud-native” way. Whether we deliver to a public cloud or use a container fabric behind the firewall, we commonly work with microservices or serverless. A data store is as likely to be block storage or Mongo as it is a traditional database. This makes sense. Small components match well with DevOps teams operating independently (see Conway). In general, modern architecture, infrastructure, and delivery approaches support more frequent releases and more resiliency in production. All good things.
However, most apps are not new. A typical enterprise can have many hundreds to a couple of thousand existing applications. Do they sit as they are until replaced? Do we rearchitect them all? Will some move? And if so, which?
Documentation in an Agile environment is an interesting topic. The Agile Manifesto places more value on working software than on comprehensive documentation, and one of the Agile principles states, “Simplicity–the art of maximizing the amount of work not done–is essential." But does this mean we shouldn’t write documentation when we use an Agile framework? Not at all. I use these three key practices to create effective Agile documentation.
First, minimize documentation to just what’s needed to get the job done. While software solutions must be maintained and need supporting documentation (either as commented code or external documentation), there is a tendency to create documents simply because “we’ve always written them," whether they are ever read or not. Creating unneeded documents expends valuable time and is counter to delivering the highest value first. Documentation effort should be treated like a requirement if it’s not part of your Definition of Done; it should be estimated and prioritized along with other work. This means weighing the cost of documentation against the anticipated benefit.
As an Agile Coach, it’s exciting to watch a team of young agilists start their Agile journey. Some start with unbridled enthusiasm, others with fear and trepidation. They then crawl from Agile infants to toddlers learning how to communicate and play well with others, then move into Agile childhood where they begin to develop competencies and enjoy success. And then… [long pause] …they become Agile teenagers – yikes!
Don’t get me wrong – I’ve raised one teenager and have another now, and I love them even during their teenage years. There are great times at that age, and there are, well, less than great times too. Those growing in their agility go through stages similar to what my kids did. Some move through the teenage years with grace and style, some with a rebellious attitude, and unfortunately some stay in Agile adolescence way longer than they should. Being an Agile teenager is normal for a while, but just as we don’t want our children living in our basement, playing video games and eating Cheetos well into their 30’s, at some point every Agile teenager needs to grow into adulthood.
Scrum and Kanban are a great combination. With this insight more and more, Scrum Teams become aware of terms and phrases used in Kanban. Like "WIP."
When I have used this acronym in the past I have read it as "work in progress." In his book, The Goal, Eliyahu M. Goldratt uses "work in process." I realized this but didn't give it much thought.
As someone who has been trying to master the guitar for quite a few years, I always try to challenge myself with learning more complex songs. Sometimes, I'll get hooked on something extra complicated, and will find myself practicing it over and over until it seems like all the notes blend together. That's when I know it's time to take a step back and take a moment for a pause to clear my head.
A teacher of mine let me in on a trick to help with this: set aside the difficult piece, and spend a few minutes playing a simple song that uses just a few basic chords, something really hard to get wrong. What I found is that this accomplishes a couple of things:
Scrum, as you can see in the image below, and as per Wikipedia, is the method of restarting play in a Rugby game that involves players packing closely together with their heads down and attempting to gain possession of the ball.
I am pretty sure that is not the definition that you wanted to see, at least not in this blog. But, bear with me for a couple of seconds. It was not a failed attempt at a bad joke. I just wanted you to see the imagery and get a feel of what is happening. Also, I wanted to throw some light on the history of that name. How did a Rugby method give its name to the popular Agile methodology that we use almost throughout the software engineering world?
I would consider myself a fan of the Agile approach to software development. In fact, I would even say I am mostly a fan of the Scrum framework.
I appreciate the ceremonies that transpire as part of an Agile team utilizing Scrum. I enjoy releasing software often, with incremental features being delivered to customers to utilize. I like to see my team's velocity be tracked and analyzed over time — comparing ourselves to other teams contributing on a given initiative. The end-of-sprint demos are something to look forward to as well — with customers and all teams in attendance — seeing the fine work completed by all the feature teams.