Meet Chet Rong. He is the world's WORST agile coach. You should watch this funny skit and make sure you don't do anything that Chet suggests. Today we have 'The Wrong Way to do Team Structure'.
It's Chet Rong again. The world's WORST agile coach. You should watch this funny skit, but make sure you don't do anything that Chet suggests. Learn 'The Wrong Way to do Agile Specifications'.
What's the best way to encourage agile teamwork? In this article we look at the best practices that underpin high-performing agile teams and make them more than the sum of their parts. We also tackle the thorny matter of discipline. What should be done if a team member doesn't measure up?
The advice to walk around in the organization is often presented under the Japanese name Gemba, which says that one ought to be there where people are working, in order to understand how well they can do their jobs and what they need from you.
I don't know about you, but I always feel a little nervous when it comes to writing Agile stories. I often worry whether I'm the best person to write them and if I've got them right.
Lets leave aside the fact that software is a damn sight more complex than small plastic bricks, lets leave aside too the fact that Lego makes a fine kids toy but on the whole we don’t use it to build anything we use at work (like a car, bridge or house), and lets pretend these people have a point….
In this post we are going to look at the benefits of working with version control and the difference between two of the most popular version control repositories, GIT and SVN.
In this talk, Dave will strive to make sense of the impact the Lean Startup Movement (of which 500 Startups and its portfolio companies are great fans of) has had on entrepreneurship, particularly in Silicon Valley, where Dave is based.
About 2 years ago I noticed that I no longer recognized some of the more recent Scrum trainers. I really want to get to know the wider Scrum community, and I decided that the way that I would do it would be by doing interviews and then sharing those videos.
Generally, I want to tell all these people the same thing. If you really enjoy the work and want to be successful in the business for a long time, you should try to make decisions, think like, and become an engineer’s engineer.
As they say, with great power comes great responsibility. It was a shock to the system to have this level of autonomy. I've worked in various types of company over the 15 years people have paid me to develop code, but nothing prepared me for this.
On Apollo 13, tensions ran high, but, instead of blaming each other for the mistakes they made, they concentrated on the system of the space craft and how to work with what was left of it. The same is true for your development process. Focus on the whole system instead of blaming each other for slow releases of new features.
Strategic work is difficult. It requires thought and discussion. Tactical work is difficult in a different way. Tactical work often demands answers quickly. Strategic work, assuming you don’t postpone it and create management debt should take longer because reflection is a good thing for strategic work.
The question was: Why are engineers good project managers? Yeah, I know how many thoughts, memories, and personal experiences whirled in your mind at this very moment :)
A while back I was talking to a manager who complained that “no one” in his organization was “accountable.” Of course, he exempted himself form that category.
The final step was to identify concrete actions that the Scrum Alliance organization and membership can take to move toward the goals associated with specific parts of each model.
Empirical approaches to product development such as Scrum and Lean Startup encourage us to leverage data to make decisions: We use product increments or MVPs to gather the relevant information from users, customers, and other stakeholders.
This post identifies two visions for successful leadership within the Scrum Alliance. See also: Acceptance Tests and Concrete Actions (& Participants).
This video explores how Acceptance Driven Development can be implemented within an Agile environment, using Business Stories whilst supporting both Agile and Structured development.
The courses I'm doing in Singapore, Sydney and Auckland (end of June/early July) will be the last courses I will do by myself. I will practice what I preach by delegating almost everything to the 50+ licensed facilitators.
See how models for 4 acceptance tests were put into lego form and video taped for you to see.
Software Estimation – the way that most of us do it – is broken. As an industry we’re bad at estimating, we've been bad at it for a long time, and there’s no evidence that we’re getting much better at it.
One problem with many (maybe most) software development organizations is that they inadvertently create perverse incentives, rewarding undesirable behavior and creating confusing and chaotic environments that, despite best efforts of all involved, seem to only on a hit or miss basis produce the desired result.
After working as a sales manager at two different Agile organizations I am often asked if sales can be Agile, and if so, how is it implemented?
Obviously some job titles appear to have more clout than others, and obviously some titles would be more desirable for a software writing professional to have, but a job title alone doesn’t convey any real information.