This is a great video on applying Agile to the home. There are a few things that impress me about this video:
- Do what works: When applying Agile software development in the home, Bruce did not try to apply all the practices and principles of any single agile methodology. He did not try to name things according to any particular dogma. Bruce used names and practices that made sense for his circumstances.
- Everyone needs to be agile: While listening to the video, my mind was spinning with various other applications of agile principles. Every company, every organization, and even every individual needs more agility. We’re seeing a wave of applications, and we will continue to see more.
- Remember what it means to be agile. The pre-software development definition of agile is the ability to act quickly. We sometimes lose sight of that when applying a particular agile methodology. We think that being agile means holding sprint planning meetings and retrospectives. What we really need is to constantly be thinking about ways that we can quickly adapt and change to focus on delivering what the customer actually wants.
- Basic principles that can help: Bruce went through three main points: adapt all the time, empower your children, tell your story. These three things apply in the office as well. Being agile is being able to adapt all the time. The best people to determine how this can happen is the team - empower them to make changes and try new ideas. The final principle, tell your story, is just as important in building software as it is in the family. Teams need to remember the vision, and each member of the team should be able to articulate why they are doing what they are doing.
I’m excited to apply these lessons to my teams at work, and I’m excited to find ways to apply these principles in the things that I do outside of work.
This is an extremely lightweight introduction to Kanban. If your team is having a hard time getting started with more prescriptive agile frameworks, start where you are using principles of Kanban to visualize your workflow, set WIP limits, and then address bottlenecks just-in-time. You can then start to use Scrum activities if you need more tools and more disciplined planning.
Alice: Would you please tell me where to go from here?
Cat: That depends a good deal on where you want to get to
Alice: I don’t care much where—
Cat: Then it doesn’t really matter which way you go.
Article: Printed Books Will Stick Around - Response: Opportunities in eBooks BECAUSE of slowing growth
A couple of notes/thoughts on this article:
- In the current model, I prefer to read some books in print, and some books in digital format.
- Because of the different types of screens, people prefer to buy a gadget that could conceivably be used as a reader (tablet, etc.) and then when they realize they don’t like reading on it, they stop buying ebooks. At that point, they’re so distracted by their new toy (tablet) that they read less overall. The tablet might not just slow growth of ereaders, but of reading in general! Were you able to follow that?
- I was interested in this: “The fact that an e-book can’t be sold or given away after it’s read also reduces the perceived value of the product.” — That will change eventually, won’t it?
- That leads to another point. What has to change about the current model for eBooks that will help to once again increase the growth. First, e-ink screens need to be able to accomodate other content. Will this ever happen? I’m not sure.
- Second, what has to happen to allow eBooks to be sold or given away after they’re read?
- There are interesting opportunities in the eBook market, BECAUSE of slowing growth. Thoughts?
Source: The Wall Street Journal
Improving your Retrospective
The retrospective has the power to be the most important element of a Scrum team. Many learning organizations use the retrospective or “after action review” to learn from mistakes, reflect on successes, and identify actions to improve things going forward. Typically, the three questions for a retrospective are:
- What went well?
- What didn’t go well?
- What are we going to do to improve?
I would propose a slight modification to those questions:
- What did we expect to happen?
- What actually happened? (the good and the bad)
- What can we learn from the gap?
- What would we like to do about it?
- Who will volunteer?
How is this different? Well, first, you are starting by reflecting on what exactly you had set out to do at the beginning of your sprint. You might remember the fact that you were never all that confident about your plan in the first place. You might think about the vision you had and where you had hoped you would be. Then you have a context to frame the good and the bad in. Based on our expectations, what went well? what didn’t go so well?
The focus now becomes bridging a more concrete gap that we’ve identified. Coming up with action items is one thing, finding volunteers to commit to them is another. This principle of self-organization is just as important in the retrospective as it is in the rest of the areas of scrum. If you don’t have a level of accountability in your retrospective, you probably will fall short in other areas as well.
I read a story this morning about an organization that uses retrospectives effectively. DTE Energy - the Detroit power company - had to respond to an emergency situation. The organization already had in place the discipline of “After Action Reviews” (AAR). During their crisis, many of the team members carried pads of paper with them with the headline “AAR Observations” at the top of them. While working to restore power, everyone on the team was aware that they would need to be able to help the organization learn how to improve going forward.
This leads me to my last point on improving retrospectives. If you are to be truly effective in your retrospective, the team needs to look at each sprint as an exciting opportunity to learn. When you go to a lecture or class excited to learn, you almost always take a pad of paper to jot down lessons learned and action items. Don’t let your retrospective be a time where you struggle to remember some of those lessons learned. It doesn’t matter what you use - a pad of paper, google docs, your favorite text editor - but if you see your sprints as exciting opportunities to learn, you will be taking notes along the way. When you get to your retrospective, you will already have great insights and action items that will help your team to improve.
How have you made retrospectives more effective on your team?
Source: amazon.com
The Fifth Discipline: Must Read
Every once in a while you read a book that literally has the ability to change your life. I can think of a few books that I’ve read that have had this affect on me. There are a couple things each book has in common. First, they are packed with timeless principles. Principles are true yesterday, today, and forever. They can be applied across a wide variety of situations and disciplines always with positive results. Second, they force you into action. Obviously, you must always choose to act, but these books are so packed with opportunities to act that you are continually pausing to consider actually putting down the book and applying the principles to a current problem or situation you are facing.
The subtitle of The Fifth Discipline is “The Art & Practice of the Learning Organization”. A learning organization is one that “makes key decisions based on shared understandings of interrelationships and patterns of change. Learning organizations have shared vision and collective ownership. Within a learning organization there is a great deal of trust and people feel that they can engage in dialogue and discussion about how things really are. When you are a part of such an organization, you are able to act with purpose directed toward a common vision without constantly reacting to the reality of your current environment.
The book teaches five disciplines:
- Systems Thinking
- Personal Mastery
- Mental Models
- Building Shared Vision
- Team Learning
I need some time to digest before writing another few posts on how I’m going to apply this to my career and life. Stay tuned for more!
Source: amazon.com
We aspire to be a place where people can have uncluttered, meaningful connections. Communication is important. Like in the real world, context is important…. It’s never fun to be late to a market, but it does afford us the opportunity to talk to users to see what needs aren’t being met, what they like and don’t like,
Source: CNET
DC Scrum Users Group
I have always wanted to go to a Meetup and tonight I finally did. If you don’t know what a Meetup is, checkout the website, find something you’re interested in, and then just GO! It is a fantastic way to meet new people, learn about a topic of interest, and be able to contribute to a cool community.
The meetup was sponsored by a local consulting firm and they provided pizza, facilitation, structure, and a bit of instruction. The participants ranged in experience from those who were brand new to Scrum to those who have had years of experience.
The focus of the meeting tonight was on actual questions posted in Agile forums around the web. We talked in small groups about the actual answers to the questions as well as what about the questions “smelled” a little funny. Some of the questions were good questions while others reeked of Waterfall Evil!
Here’s a brief summary of what we discussed:
Q: The first question talked about requirements traceability. The person wanted to know: Why does Scrum so blatantly ignore traceability by allowing users to track requirements on a whiteboard with post-it notes?
A: We really had a lot of disagreement on this issue. Everyone thought that there were different levels of detail that needed to be tracked by teams through the developmentprocess (full SLDC). Eventually we came to the consensus that the questioned smells because the person is probably really concerned with being able to track things through a series of handoffs (as in traditional waterfall projects). We also discussed that tracking key information from sprints, documenting the results of sprints, and finding ways to gather data about your requirements so that you could improve in various ways were all good practices on a good Agile team. Being able to “track” things like velocity, estimates, and other historical data is good but making sure that continuous improvement is the goal is paramount. Agile teams should also make sure that they are using the lightest tool possible for the job. Don’t use a tool because it has a lot of cool features. Use a tool because it facilitates your highest possible efficiency. Agile Manifesto: we value comprehensive documentation we just value working software more.
Source: meetup.com
Want to know what a #ScrumMaster does? This is a must see video to see #Agile in action (not just for geeks). Get a better understanding of what my new job is and see how it applies to the job you do as well!
I don’t know why I hadn’t seen this video before today, but by the time I had finished, I knew that I made the right move going to Hobsons. Not only will I be getting better at the process he describes in this film, but I’ll be using the principles to solve important challenges in education.
I am certain that we will get better at solving the challenges of the world by using more iterative and incremental approaches that help us to fail more quickly so that we can find the solutions that work.
I’ve recently been thinking quite a bit about the application of Scrum/Agile/Lean to all kinds of challenges outside the world of software development and it’s great to see such a tangible example of that happening. What’s even better is that they didn’t shy away of calling it Scrum and they didn’t really feel the need to drastically change the process to their industry. They took the process with all of its “weird” language and implemented it as loyally as possible. They were so successful that they got bored with building cars and decided to tackle Polio. Amazing!!
Source: youtube.com
