Mindshift Forward

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

(* Source ) As a developer I know how annoying it can be to be measured, mainly because when this measurements information starts being shared, you start to get questioned on things that you otherwise would have been left alone to work in peace. Having metrics is one of most harmful tools if you use them wrongly, and I'll try to share with you my insights and experiences on this matter. What are we measuring Most likely the organization that you work on, is already measuring something. The organizations that are making an effort into making the agile transformation, tend to emphasize initially in the values, principles, and practices within the scrum teams and their direct ecosystems, and let the teams evolve and accommodate while they keep on working. This is a good approach. What usually gets overlooked by the scrum teams nonetheless, are the metrics that are kept -unless stated otherwise- to bring measurements on how we are going during this transition. Sometimes the o

Hello to all of you, especially the ones who are managers and are struggling with this question! In two of the last three organizations I've worked for, this question was raised. The same two out of the three were the ones under an agile transformation process. I don't think that's random, but let's not jump to conclusions just yet. Here's my attempt to clarify the actual problem and solve it, but to do that we'll need to brainstorm together a few things: What is being unproductive? (Might these be some of your assertions?) "Takes too long to get what I want." "Things are never 100% done." "Nobody seems to feel the pressure." "They don't look busy." "Stories take longer than estimated." "Delivered on time but full of defects." "We used to do things faster." How does a developer look like when he's staring at nothingness and losing time? How does he look when he's

"It doesn't matter, all this -estimating- effort is lost time, since they'll -Product Owners & Stakeholders- have to accommodate to the truth, and we'll have to do overtime to get there either way"  - an anonymous developer This phrase is something I've heard in my agile coach experience. Teams accepting the fact that externals do not understand how estimating should work, already abandoning all hope to make a change in the way stuff is done. The first thing that waved in my mind as a warning flag, is the "Us vs Them" perception. Having sides, is a clear notice that we are not working towards the same goal, or under the same understanding of what "having the same" goal really means. It's my hope that with this short note, I can help as many Developers, Product Owners, Product Managers and Stakeholders to get to the same page once again. How is it badly used Take a look on some of the example situations I can think of top of m