Turn it off and on again. Surely, this can’t be true for a critical piece of equipment like a jet fighter. Especially a jet fighter that cost one Trillion Dollars to develop. This is exactly what happens onboard F-35 Joint Strike Fighter at times. It’s radar just “stops working” and only way to fix it mid-flight is to turn it off and on again. Imagine that in combat situation. How do you fix this? A better question is, how do you avoid having such issues? Have a look.
As Peter Drucker said, “Concentration is the key to economic results. No other principles of effectiveness is violated as constantly today as the basic principle of concentration.” Ken Schwaber and Mike Beedle mentioned five Scrum values, one of which is Focus. In most organisations juggling with multiple projects and tasks is considered an admirable attribute. But does it really solve problems? Read on.
Teams need to prepare backlog items for future sprints. This is called backlog refinement. Do the team members need to know the business domain? Or is this the job of the Product Owner? This article puts the emphasis on the team, which is an interesting take on backlog refinement. When was the last time you evaluated how backlog refinement is done? Here are 5 tips which can help you improve your approach to backlog refinement.
What are the elements of a good story? A regular story, not a user story. Well, a good story has a well thought out theme with an engaging introduction that clearly sets the scene. And there’s always a conflict in the plot, or problem to be solved, that involved the main character. And finally a proper resolution that leaves the reader satisfied that the story had reached its ending. How do these apply to the way we write user stories? Read on.
It’s a commonly asked questions. It divides opinions. Should the Product Owner attend the Retrospective? Or the Product Owner should only be there on invitation by the Scrum Master? The Scrum Guide indicates that the Product Owner being part of the Scrum Team should attend the Retrospective. Nowhere it states that the entire Scrum team must always attend the Retrospective. Read on to see different aspects of this seemingly simple question.
Is all feedback related to your product created equal? Who should you listen to? Someone who’s new to your product? Or someone who’s been using it for a long time? Does “age” of the user, i.e. how long that user has been using your product really matter? Here’s an interesting perspective on which users should we focus on.
Instead of focussing on silly ideas like lines of code or some other fancy but equally useless metrics, what if we use software metrics that can be tied, relatively easily, to stakeholder value in projects? Especially, if these can show valuable information to people invested in the project outcome. Like Google Page Rank, what if we use Code Rank. We can use Type Rank to create a release riskiness score. And measure cohesion. Cohesion of modules in a code base can loosely be described as “how well is the code base organised”? Here are 4 code metrics that are uncommon but rather useful.
Working for a someone who’s task-oriented and has a high need for achievement can be motivating. But if that high-achieving manager is also an office-obsessed, iPhone-attached workaholic, it can be quite the opposite. How to deal with workaholics? How do you go about sharing your perspective and how do you approach them? What to say and what to avoid? Here are a few practical tips.