Tips, Expertise, Articles and Advice from the Pro's for Your Website or Blog to Succeed
Most of the Job Postings you will see will have the term Agile Process mentioned somewhere in their Job Description. If you talk to Developers or Managers in your network, most of them will tell you that their teams are using Agile Methodology.
So I believe it is fair to say that the term Agile Process is trending nowadays in Software Industry, and using Agile Process in your team is as cool as using AI/ML in your code. Agree?
Agile is one of the trendiest concepts in the tech world.
First theorized in 2001, Agile encompasses several frameworks such as eXtreme Programming, Crystal, or Lean Software Development (LSD), with the most widespread being Scrum.
A few years ago, when companies started embracing Agile, they would bring in a consultancy firm to help come up with a strategy for the shift. They would hire some Scrum Masters, provide basic training to their teams, and proudly declare: “We are Agile now.”
But that statement couldn’t be further from the truth. More than a methodology, Agile is a philosophy, and adopting it means that everyone involved should get on board with a complete and profound transformation. A transformation that, oftentimes, fails.
This week we have another episode from the 2021 engineering leadership conference INTERACT. In this live conversation I interview Henrik Gütle, GM of Azure for Microsoft Canada.
Henrik joins the podcast to break down the results and key takeaways of Microsoft’s research into the impact of remote work on developer velocity - and what engineering leaders can learn from it.
To fight the wars of the future the US Air Force tasked a small group of software engineers with a simple job - revolutionize the way the military thinks about software development.
The group tasked with this not-so-tiny problem came to call themselves “Kessel Run” after the famed smuggling route used by Han Solo in Star Wars.
It used to be that when an IT company needed something translated, they had to send the translator an Excel file to work with — not exactly convenient. Later, translators began working with CAT (computer-assisted translation) tools, such as Trados or MemoQ, which was a big step forward. To this day, CAT tools remain an ideal option for long-term projects that require a custom setup, but they are still too ponderous and inflexible for Agile projects.
And then LMS/TMS (Localization Management System/Translation Management System) tools appeared on the scene. Unlike desktop-only CAT tools, these localization platforms do all their work in the cloud and are extremely flexible. The advantages this presents for both the client and the localization agency are self-evident.
What leads teams to game metrics within their organization?
On a recent episode of Dev Interrupted, I talked with agile expert Ray Elenteny, Principal Owner at Solutech Consulting, about how people game dev metrics and the underlying issues in culture & leadership that lead to it.
How do we know when a user story is "done?" Can we say that the user story is done when it is coded and all acceptance tests for it are passed? Business representatives may say yes, but they do not know all the peculiarities of software development. So, such criteria as quality are not fully visible to them.
Or let’s have a look at another situation: a new feature that changed the business process was developed and tested according to the best software practices, but users struggle to use this feature because they are not sure about the changes this feature brings. Maybe a proper user manual or user training is needed in this case?
The Scaled Agile Framework® (SAFe®) came into being to help modern enterprises implement Lean-Agile development at scale more effectively and smoothly. So, if an enterprise wants to implement this framework to reap the maximum benefits of the Lean-Agile Development at scale, it is essential for it to absorb Lean-Agile culture, Lean-Agile mindset, and Lean-Agile principles at the personal, intellectual, and leadership levels. This thorough absorption at all these levels forms the base on which SAFe can be implemented effectively.
The successful SAFe implementation consists of these factors:
A couple of months back, I wrote a blog titled 'The price of excellence is eternal vigilance' that was published on my company's intranet portal, tying it to the need for constant monitoring/surveillance of data flowing through a distributed SaaS system. The quote is directly from the stellar TV show 'Better Call Saul.' I've recently come across another quote from the same show which I believe is appropriate for the design of a minimum viable product (MVP). This credo can hopefully help agile development teams find that perfect balance of delivering the right amount of value with minimum effort.
As defined popularly, a minimum viable product (MVP) is an initial version of a product designed specifically with just enough key features, that can be delivered to a few customers to validate its purpose and vision that in turn, enables the development team to get early feedback. This early adoption process is beneficial to both parties as the customers spend less to try the product, and the developers and product owners (POs) will get their assumptions validated.
In today’s turbulent and rapidly changing business environment, Lean-Agile working models have helped businesses become more adaptive and flexible. With a focus on creating highly engaged and empowered teams who act on fast feedback and pivot regularly to maximize business value, it’s easy to understand Agile’s present popularity.
Yet while the “Agile” concept is good in theory, it can become overly-idealistic. Many organizations commence their transformation journey with the best intentions only to find their workforces soon shift back into a production line driven by uniformity. This is the critical point where progress can begin to stall.
“Knowing yourself” is probably the most underrated yet highly significant aspect of management at any level. A truly self-aware project manager would be highly attuned to their own behavior, emotions, and reactions. Self-awareness also keeps us humble so we can acknowledge what we have yet to know and understand the crucial attributes of our own personality.
That’s why the process of efficiently managing others would naturally start with managing oneself, and being self-aware is a vital prerequisite to do so. The most assured project managers perform well in testing times because they know their limitations, strengths, and weaknesses. In a time of crisis, they would be able to reflect and quickly work out a solution instead of going into a shell. In a way, it all comes down to leading yourself before attempting to guide anyone else.
To recap, the goal of Agile, as in true Agile, is to promote a disciplined project management process. A functioning Agile process embodies the philosophy of being agile as well as adopting and using an Agile framework, such as Scrum or Kanban. True Agile is adaptable and easy to assess and improve upon, it relies upon a leadership approach that encourages teamwork and self-organization.
Now, with true Agile covered, let’s take a look at fake Agile.
In their book Discover to Deliver: Agile Product Planning and Analysis, authors Ellen Gottesdiener and Mary Gorman introduced a simple and powerful model to guide product discovery effort – The 7 Product Dimensions model. This model identifies 7 areas (product dimensions) that we will need to explore – through collaborative questioning and reflection – in order to learn more about the product. The dimensions are User (who the users are), Interface (how they interact with the product), Actions (what they can do), Data (what data the product needs/stores in order to work), Control (rules & constraints), Environment (platforms that would host the product/on which value will be delivered), and Quality Attribute (customer’s expectations around quality, usability, etc.). The premise is simple: if we ask good, powerful questions about each of these dimensions, we’ll learn a great deal about this product we want to build, which will help us build a better product. You can find more information about the 7 Product Dimensions framework and canvas Here[1]
Here are some of the questions that we could ask to discover more about each product dimension:
For a scrum master in a scaled program environment, coordinating work between multiple scrum teams can be a little bit like managing home construction. In a new home community, future homeowners have made their selections of a floor plan, location, and amenities (determined their minimum viable product), and negotiated a price and put down earnest money (funded the value stream). Now it is time for the construction manager to convert the initial investment into revenue by delivering a completed house that meets the expectations of the company they represent, of regulators in the form of building codes and occupancy permits, and most importantly of the homeowner.
Likewise, scrum leaders need to satisfy their stakeholders and customers with working products that meet requirements and regulations, generating a return on investment, innovation, and enhanced reputation. To accomplish this mission, they must coordinate the work of multiple teams using the best engineering practices to sustain a continuous delivery flow. In software delivery as in new home construction, maintaining a continuous flow while providing a predictable time-to-market requires the mastery of three primary activities: scheduling work, managing dependencies, and ensuring that the product passes inspection.
There are times when a superhero swooping in to solve our problems would be more than welcome. In Agile development, this occurs when there’s too much to do alongside the current sprint.
And this is where Batman comes in. But I don’t mean the caped crusader himself. Rather, a member of your team that fills the Batman role.
Agile Velocity is arguably the most popular software development metric in the world. It's a very powerful metric when used for individual team sprint capacity planning. And there are two things we know about power... it comes with great responsibility and it corrupts.
When agile velocity is used for anything other than individual team sprint capacity planning, very bad things can occur. In fact, when misused, Agile Velocity is the most dangerous metric for software development organizations. Unfortunately, every day Velocity is abused by executives, engineering leaders, product leaders and even developers.
The first thing that comes to my mind when I think about a ninja is the movie “Teenage Mutant Ninja Turtles” – the 1990 version, not the 2014 reboot. Modern culture views a ninja as a sort of superhero. According to Wikipedia, a ninja (or shinobi) was a covert agent or mercenary in feudal Japan. Folklore depicts the ninja as having legendary and often supernatural abilities. Sound like any Scrum Master you know?
You may also like: What Makes a Scrum Master Successful? Insights From 30 of the Best