Skip to main content

Are Tools ruining the Agility in “Agile” teams?

Manifesto and the role of tools within the world of Agile Software Development?
Part 1 of the manifesto: “Individuals and interactions over processes and tools”
Are the tools we use to support our Agile Software Development ruining the actual agility on day-to-day basis? Are these tools affecting the chemistry of the team?
Are the companies that sell these tools feeling the pressure to innovate and to keep owners and stockholders happy? Then the innovation turns out to be tipping the manifesto statements to the right side (contradicting the manifesto) because the decision makers in companies who buy these tools may want the tools that are all about tracking, measurements, and reporting without thinking how useable these tools are for teams on daily basis.
I am putting a lot of questions in this post and I am not going to necessarily give you answers to these questions. This post is more about having you think about these things and realizing whether you as a software developer are already impacted by these tools or specific features of these tools. Are you asked to use certain features of these tools and you think that these features cross the line and tip the weight to the right side of the manifesto which really means contradict the manifesto itself?
Over the years I used many different tools that supported waterfall and agile development. Some of the more recent tools for agile development have been:
  • Rally
  • PivotalTracker
  • Trello
  • Jira
  • Asana (not necessirily build for agile but for overall task management)
  • OneNote (yes, I said OneNote)
I am not going to praise or criticize specifically any of these tools. Some of them are simple and get the job done without forcing you to do it certain way. Some of them are more complex because they have all kinds of features for measuring and reporting and this generally looks attractive to the leadership team who may see this as an opportunity to closely track the work that the team is performing.
The question becomes, who is supposed to pick the tool? Are the members of the development team supposed to recommend a tool that helps them get the job done the best way, or is the leadership team supposed pick the tool that works better for them, or is there a tool that keeps everybody happy?
What did we do before the age of tools? Yes, we used Post-it notes !
A simple board with Post-it notes divided in a few columns did the job for a team in one location. It was a very simple approach. The tools should also keep things simple. They should just take it one step further without negatively impacting the progress, the creativity and agility of the team. On the other hand, if you go one step too far with the tools, the team will know if their agility is impacted and if the fun-factor is gone. We all know that if you take the fun-factor and agility out of the team, then the team members are not operating on their own terms any more; the authenticity slowly goes away.
Almir Mustafic


Labels:

Comments

Post a Comment

Popular posts from this blog

Brand New programming language and one solution OR …

Brand New programming language and one solution OR Two existing programming languages, one solution for EACH? I understand that there is no right or wrong. It all depends on your software architecture, team structure, team skills and other factors, but I still want to explain the scenario as it may look familiar to some. Let me explain. Let’s assume that you have microservices and common libraries in two major programming languages. You have some teams who are experts in one and some teams experts in the other programming language. Now you need to come up with a solution for a scenario that all teams will need to leverage. Let’s assume that your cloud platform has an off-the-shelf approach for this but it is supported by a 3rd programming language that your teams do not have much experience in. What is the right thing for your organization and not just from the technical point of view? A) Do you embrace what your cloud platform gives you off the shelf and implement thi...
Post a Comment
Read more

10,000 foot level view in technology

10,000 foot level view in technology: How useful is it? What can be done at this level? If the 30,000 foot level is the CTO level, then consider the 10,000 foot level as the level that software engineering managers and directors operate at. To achieve the success at 10,000 foot level, you as a software engineering manager need to dive deep into technical details, help the team lay the foundation from BOTH organizational and technical side. It is the little moves that get the team to this level. Once the team’s applications and results at that level, then you as a manager have ability to perform the high level analysis and troubleshooting without necessarily being in code on daily or weekly basis. Therefore, your ability to troubleshoot technical issues at the 10,000 foot level is a testament to the great work of your team. Go TEAM !! Almir Mustafic
Post a Comment
Read more

Programming languages to teach students in high-school and university

Python-like or C-like as the language to introduce programming to students in high school and university? The question is: Do you introduce programming concepts to high-school/university students using languages that handle memory and other things for you or do you start introducing all of these concepts in languages like C that require you to understand all aspects. I will tell you what worked for me. I was introduced to programming in grade 10 using Basic programming language. There was a version called Better Basic and also Quick Basic. Then in grade 11 we learned procedural programming in a programming language called Turing (not Turing machine but a Pascal-like language developed by University of Toronto for teaching purposes). Then a year later, I started getting interested in C and C++. As you can see, I eased into the languages that introduced me to NULL exceptions and memory leaks :) With this approach I was not overwhelmed and this set up the foundation for a fun journey ...
Post a Comment
Read more