Mindshift Forward

I've talked before about breaking the glass ceiling in my last entry, and I would like to extend a bit,  and talk a bit about the things that are happening around the teams "working in Agile". Many organizations going through the agile transformation have a  Water-scrum-fall framework, (coined term by  Dave West placed in Forrester ). Let me do a quick overview of this perspective: How do we get a project to start in an organization under this framework? Usually you got in an organization just a few budgets approved for massive projects, of yearly or wider perspectives, for which they had some kind of previous analysis. Through some kind of large study you get to an approval, which leads to a design proposal. Only a few big projects get funded. And sometimes the decision of which projects are funded are based on ROI or some other finantial modeling (yay, economics!). As if the market trends will help you see what will be useful or even used in the future, or the

We think we are doing well but we are not Nowadays everyone is agile, "yes we are doing agile, so therefore we are agile"... Let's do a deep dive on that: "Why do you think you are agile?" "Well we do all the ceremonies scrum expects us to do, most of the times, dailies are close to 20' or 15' mins, we work in teams that can self organize and the teams deliver demos to business teams regularly in 2 weeks iterations". "And when does the user see the product?" "Well not until this set of features is finished", "And when is that?" "In 9 months". Organizations learned how to keep the appearances of agile, and many think that, by doing what they are doing, they are on the right track. There's a lot of implementations that at the top, are still using waterfall, but with agile terms. Resistance to change isn't new in IT, and there's quite a jump out of the comfort zone people need to do.

Having worked in IT for quite some time now, more than once teams had to dig into quality and how much would it improve by doing this or that. The main issue there was that no matter what we thought on it wouldn't "improve quality" because quality is the client's perception of our work and that had a lot to do more with the advertisement we do to the product rather than the amount of good work we do, right? Let's try to clarify it by explaining what I learned in my experience. What is quality? Many times you might have found managers concerned about the quality of the product their teams are delivering, asking the teams to take ownership about it, but right away this self organized teams find themselves questioning themselves, what is quality really? Wikipedia will tell you that it's  a pragmatic interpretation as the non-inferiority or superiority of something; it's also defined as being suitable for its intended purpose (fitness for purpose)