Empirical process control relies on inspection, adaptation, and transparency. And even though these three main ideas are the heart and soul of scrum (the go-to agile software development framework), it kind of sounds like a sales pitch to most of us.
This article is about transparency and how much of a difference it really makes for your project’s success.
The “transparency attribute” is part of all facets of the agile software development process. You can be more or less transparent in your meetings, with your progress reporting tools, with the actual increment quality at the end of the sprint, with your risks and opportunities, and so on.
At some point on any given project, you are going to be tempted to sugarcoat news to either your team, your boss, or your stakeholders in general and this is a consequence of all that you’ve learned in your life. It is just common sense that if you encounter a setback, no matter how big it is, you simply work a little extra on it so you can keep everybody happy with only good news. Similarly to when you were young and you broke one of your mother’s dishes by accident: you just went and glue it up all before your mom got back from work, right?
Wrong! A mother always knows if something is out of place in the house and she would eventually find out. Mine always did and she would always get angrier at me just because I lied about it and, if she would have known about it sooner, she could have gotten a replacement on her way home.
This is how things work for projects as well: Clients always find out, and the minute you are not honest with them Murphy’s law is going remind you why we want the transparency attribute to be at its highest degree. An impediment comes up and if you don’t tell your scrum master about it, it is just going to get worse and worse to the point where you won’t deliver by the end of the day.
This applies to all of your meetings and day-to-day communication. You must fill in everybody involved in both good news and bad news. Your product owner must be informed about what increment is realistically expected at the end of the sprint, and he must keep the stakeholders posted about it. The development team must set those expectations to reality during the sprint planning meeting.
Everyone must trust everyone else. This encourages collaboration between all parties involved to get the objective done. If you have an issue, you tell me about it and we can work on a fix for it together like the team we are.
So keep it real with your team, your bosses and your stakeholders, and also keep your scrum or kanban board updated with what’s actually going on. If you find something small, inform everybody right away. And if you find something big? Inform even faster! Remember that we are partners in this.
Keep coming if you want to know what I have to say about adaptation and inspection, the other two empirical process to control main ideas.
Are you looking for a firm that makes Agile Software Development work both ways?
Contact Us. Let’s set a Dedicated Software Development Team to work together on Agile and fluidly make your new footprint or gain new customers. Count on us for on time and on budget software products.
