Mindshift Forward

<< Part I Strategy level Plan at multiple levels Strategy: Having a strategy is more than just having a set of objectives collecting dust, possibly at some cloud unaccessible space, that no one minds looking twice. Strategic initiatives Are important to filter aligned from unaligned ideas. You should use them regularly to keep your aim towards the objective. The project you had planned might attack what you think will happen but not address exactly what you want to happen. If new ideas or initiatives come to you, in a product leadership position, and your vision and end goal is clear you might want to compare that objective with the new initiative and take that if it has a more likely to be right. Budget Target What we want to happen Strategic themes / Initiatives Forecast What we "think will happen" IS different than "want to happen". BE CAREFUL HERE Resource Allocation People and resources we need to make it happen Operat

For quite some time I've addressed the budget topic from different approaches.  I recently had the opportunity to read some things from Kenneth Rubin , who had a few things quite clear in that regard, but with a different approach, that I hope I rephrase and state here in the most truthful way I can to you, with a few drops of my perspective and experience on the matter. Traditional Budgeting "We need to define the yearly budget per cost center. Remember to be as precise as possible, you are going to be measured against that" You might realize that this process. Requires detailed up-front financial projections and business plans. Promotes greed for finite resources. Instills a use-it-this-year or lose-it-next-year mentality. Leads to utilization-based planning and execution. Fosters rigidity - Budgets are hard to change. Complicates things in a project-based environment where the projects touch many cost centers. Biases teams towards least-risky soluti

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)

Usually when you explain agile for the first time to any audience, you put focus on reviewing the values and principles, with a quick example on how minimum valuable increments will help you reach safer to the goal solution, incrementing your knowledge base on what you are trying to solve. on each delivery. A common example is that of the car being built with the waterfall and the agile approaches. As a first take on agile, this always proves to be clarifying. But sometimes difficulties start to show up when this is put into a real situation in a organization facing an agile transformation. Most likely, if you are in a company which already has an IT area, it already has a software product -or set of products- that covers everything they need to keep the business running. That means, to follow the analogy, that you "already have an old car" , so the customer might have a clearer idea of what he's expecting. Under this circumstances, is when the concept of MVP -a