Cost of delay and opportunity cost when you don’t build quality in
Let’s talk about cost of delay – the cost of having NOT done something. Basically the opportunity cost of choosing to do one thing over another. Seems simple enough but it’s not.
Not everything needs to be “value-add” time
Busy. I’m busy. I’m too busy. I don’t have time to think – hell, I barely have time to sleep. Between work commitments, friend commitments, relationship commitments, and building my own brand, I am left with little time for myself. I’ve gotten into a pattern of trying to make every second add value (work-type value). What does it turn into? Burn out and ineffectiveness, and that is not what anyone wants or needs.
Strategies for product owner across multiple teams (with different products)
A product owner should be dedicated to one team. Or no more than two teams working on the same product with the same product backlog. But what about a product owner who we spread across two teams with different backlogs working on different products? We’re asking them to be two people and it’s not sustainable! This product owner told me he was in 17 hours of meetings between the two teams per week (and I added it up and it was true)! For the product owner who should be splitting his/her time between self thought, stakeholder and customer input, and team time, it’s not possible for those things to be equal or sustainable not to mention the loss of productivity when context switching/multitasking. Though unfortunately this is the non-ideal reality sometimes.
Are contractors good for supplementing Agile teams?
Want loyalty? Hire FTEs! Want an expendable workforce? Hire contractors! Want short term experts to solve problems? Hire consultants (*at a premium price)! But what if you want high performing Agile teams? What type of workers should you look to hire then?
Your introvert is showing
Introversion versus extroversion has been a hot topic over the past few years, especially since the release of Quiet by Susan Cain. In IT it is no different. Everyone knows the stereotype of the “typical developer” – the one who only wants to sit in their cube and code by him or herself all day. But it’s just that, a stereotype, based on some facts but not true for all. So how are we more inclusive of that person in Agile where collaboration, co-location, and teamwork are valued over solitude? Secondly, how do we encourage introverts to be leaders which is historically and stereotypical a role for extroverts?
Founder: Women in Agile
This work is licensed under a Creative Commons Attribution-NonCommercial-NoDerivs 3.0 United States License.