A Scrum Master really is supposed to be the person who clears the path for the team so they can run as close to full speed as possible. The Scrum Master is sort of like the pit crew for a race car driver.
Scrum and Kanban lead to the evolution of Scrumban. Combine the two approaches and receive a sum that is larger than its parts. When implementing Kanban it stipulates to "respect the current process, roles, responsibilities, and titles." This lends itself to simple integration with existing systems; furthermore, Scrum and Kanban both champion continuous process improvement and self-organizing teams. The big question is, "Can these two ideas coexist?"
What stops a lot of people from trying something new? Fear of failure and lack of confidence are two that come to my mind. Failure and “failing fast” has been a popular topic in the recent years. However, I do not see a lot of articles about confidence. To me, being confident in oneself eliminates a lot of fears.
I usually explain TDD as a methodology, then later explain it’s really a discipline, in both senses of the word. Using TDD requires discipline and confidence, not to give in to the dark side. Which may not always be so dark. Or may not seem like it.
It’s common to see people point fingers and play the blame game after a project fails. These blame games not only hurt the team members but also impact their morale as well. Is there a way to avoid these hurtful situations while focusing on improving process and identifying the failure’s root cause?
Both timebox-oriented [e.g. Scrum] and flow-oriented [e.g. Kanban] methods try to emphasize getting things done so that they can be used earlier and provide value.
If you use estimates as a way to evaluate the projects in your project portfolio, beware of the sunk cost fallacy. You would be better off to ask, “How much value does this project have for us, compared to the other projects we have to do?”
As an Agile Coach, I typically find two shifts in perspective helpful for new agile architects: first, the possibility of delivering slices of functionality, and second, the possibility of delivering slices of architecture required to support incremental delivery.
This month marks one year from the time we switched from Scrum to Kanban. I think this is a good time for us to review the impact of this change.
Scrum continues to insist that a single person play the role of Product Owner on a development project. There are too many functional and operational and technical details for one person to understand and manage, too many important decisions for one person to make, too many problems to solve, too many questions and loose ends to follow-up on, and not enough time.
In the recent times the following ideas/buzzwords are getting filled with the void of struggling, adolescent Agile.
An expert's performance can be dramatically improved with the right tools, but a beginner will not perform better with a great tool.
At the very core both agile manifesto and scrum are frameworks and not a detailed method or process. This was intentional because the founders of scrum wanted to keep it as lightweight framework which can be used by the organizations to develop the software with value.
Make sure you didn't miss anything with this list of the Best of the Week in the Agile Zone (Apr. 25 to May 01). This week's topics include the balance between talent and hard work, a discussion on the Diatomic License, and a decompiled explanation of agile.
For a look at what's been happening outside of the Agile Zone, we've assembled a collection of links including the livelihood of TDD, how to use agile for long term planning, why scrum sprints might be slowing you down, and several new amalgamations of agile-type practices.
Their product performs very well as a technical solution and is the foundation to the success of the company. Equally as important as their focus on a great technical solution is their focus on company values and culture. They put a lot of focus into the people to produce these great solutions.
In programming, defining the word "done" has a diverse field of opinions. Use this list as a jumping off point and feel free to enhance it. This will help developers in the daily decisions of crawl, walk, or run. Having alignment on these lower-level "dones" will help ensure the larger "done" is achievable.
Look-behind is one of those advanced/obscure regular expression features that I don’t use frequently enough to remember the syntax, but just frequently enough that I wish I could remember it.
Have you ever heard the expression “time is money?” In this video the author flips it around and show you why it is better to think about money being time. Invest your time to make money, leverage that money to make more, then buy back your time for a net profit. The key to success.
Remember, that tools should just support your process and not replace it. If your goals are clear to you and your team, then the tools are just implementation details.
I’d like to see stories push down to hours (incl QA), and I think there’s adequate precedence in the industry for that. AngularJS is a step towards that reality, IMO.
Corporate culture is enduring. In some ways, it defines what a company is. In other ways, it reflects it. Companies that diligently nurture a positive culture thrive. But what do you do if the corporate culture needs a little work?
Measuring agility with fighter jet sims and good software engineering. And scaling to the enterprise.
I just observed yet another conversation on twitter that started with the topic of waste in software development. These discussions seem to spin in circles. They always have, and likely always will. Why? Because they treat quality and value as attributes of what is built, rather than as relationships.
Many people think that unless you are carrying out Iterative and Incremental releases, Test Driven Development and Pair Programming you are not working as an agile developer. However do you really need to be doing all these things to be working in an agile culture?