- Happy Agile New Year! – Year in Agile Pictures
- [Giveaway] Winner Alert – How to Build a Blog Business
- Teams over processes!
- Agile in Lean Manufacturing – Yup
- NOT Doing Scrum
I spend a lot of time in photoshop. Mostly just to have fun and create something funny for the blog post that I’m writing.
This year I’ve decided to highlight some of my favorite posts, based on the photoshop picture. These, unfortunately, are not some of the most popular posts of 2011, but that don’t matter. 🙂
Enjoy, and I look forward to growing with the Agile community in 2012!
Favorite Blog Posts in 2011 Based on Pictures
[CLICK IMAGES FOR BLOG POST]
WINNER: Beatriz – Shoot us an email at [info AT agilescout DOT com] with address and we’ll ship it out!
See Our Past Giveaways:
- [Book Giveaway] – Social Media Marketing Book
- [Book Giveaway] – Executives Guide to Information Technology
- [Book Giveaway] – AgileScout and Open Source Awards – 3 Book Giveaways!
- [Book Giveaway] – Execution – The Discipline of Getting Things Done
- [Book Giveaway] – Making Ideas Happen
- [Book Giveaway] – Scrum Pocket Guide – A Quick Start Guide to Agile Software Development
- [Giftcard] – $100 BestBuy Giftcard
- [Book Giveaway] – Fatal Illusions
- [Swag] – Cool Agile Mug
- [iPad] – First Ever iPad Giveaway!
- [Swag] – 1 Terabyte Western Digital Hard Drive
[Guest Post: Craig Strong, MBCS CSM has been involved with software production for over 12 years and is currently contracting as a ScrumMaster for Sky. Having been a developer Craig has experienced first hand the effects and problems when being managed by various project management techniques and frameworks. On a daily basis Craig is responsible for managing,coaching and improving cross functional teams using Agile. Follow him on Twitter @craigstrong and blogs at www.c6s.co.uk]
Do we really need to do that?
One of the embedded issues which often exists in most cultures is the accumulation of processes. Processes make people comfortable and empowered. People are generally creatures of habit and enjoy routine. If people feel good about such things its tempting and common to see more processes emerging to strengthen or improving the existing processes. Now don’t get me wrong, certain processes and frameworks are essential and have high value to business. However sometimes where they exist, they are the main focus and not what the process was setup in the first place to achieve.
When you get a group of people together and put them on the same project they are not a team they are simply a group of individuals. By applying processes, frameworks or tools to this group it’s likely they will simply be a group of individuals using processes, frameworks and tools. Not only will this not help build a team, but could slow down the group of individuals.You don’t build teams by simply applying a framework or process. Certain processes are inherited from previous projects so they must be applied again. In some cases they didn’t even work well previously, but were in place and therefore must be re-used. There is no such thing as silver bullets which when applied guarantee success.
As the famous quote says :
Insanity: doing the same thing over and over again and expecting different results. – Albert Einstein
As simple as this sounds, it’s very true. How many of us are routinely writing and/or requesting documentation, forms or following certain processes because we are used to it not because it’s really needed. If you question some of these and ask yourself why you are doing something or why do you need this information and how is it going to be used, you may find that you don’t really need to continue with it. When you stop doing such an activity from then on, you will have free time to do something of value. Not only in such cases can you improve value, but you might just stop doing something which is devaluing the situation.
In Kanban this is often seen when you are visualising workflow. By visualising the workflow you can identify routes of inefficiency and routes to improvement. The same can be discovered when undertaking Lean analysis. This regularly proves to provide fantastic results over time. However sometimes outside the direct workflow of production it’s worth questioning other not so tangible artefacts. In doing so you may eliminate waste and identify micro-management which can and needs to be challenged. A process is not beneficial unless it has a clear value which should be easily identifiable. Value isn’t something which is nice to have, but something which clearly delivers or benefits a person, group, company or product.
So next time you are about to spend 30 or more minutes writing a report or asking someone else to provide you with a graph, ask yourself “Do we really need to do that?”
Living it Up In the Back of A Gigantic Plant
Welcome to my view. Seriously. I could not be more excited to work for this client. I’m getting to help lead a small development team better understand and deliver a new automation system for a manufacturing/shipping plant.
What excites me the most is that, as an engineer, this really gets my blood moving. I’m literally uber excited to be part of a manufacturing automation system at work. Rock on. I’m also excited about blogging about this experience. Not many Agile Coaches get to work outside of strict technology and software product development.
One of the first things I did was spend the day understanding our value stream. After interviews, process diagrams, and conversations with the team, I built out this nice old omnigraffle of a high level view of the value chain, from receiving to moving through the system. You’ll notice that we have 2 releases of our new automation system (small font).
We need to eliminate waste AND build a system that accounts for increases in cycle time. YES! Let the challenge begin.
“Walk within yellow lines…”
Now, if I can only find my yellow hardhat.
Here is a quick and dirty video on value stream mapping and the value. 5 minutes. You’re not working anyways. It’s after Christmas. 🙂
[Guest Post: Don Gray is an Agile Coach whom I have had the pleasure of working with on one of my biggest clients. There is too much to say about him. He kicks ass. You can find him blogging on his website and follow him on twitter @donaldegray] – He also purposely tries to confuse me and challenge me at any given moment.
I recently talked with a company who wanted to use Scrum for their production support team. The team had 670 defects ordered in business priority and needed to work from the top down. Corrected defects would be deployed to production once a month, except quarterly when then deployment would synchronize with new development’s deployment. No planning meetings needed and no demo prior to deployment.
About a week ago the following question was asked on the scrumdevelopment listserve:
“Sometimes, I feel ScrumMaster role is redundant. Is it possible to have Scrum without ScrumMaster?”
Once from the top with feeling
The process has these ceremonies, or meetings if you prefer:
- Sprint planning – happens at the beginning a sprint. Sprint means a time period (usually between 2 – 4 weeks and shorter is better in my experience) where the team produces the value they agreed they would. Sprint planning often divides into two meetings: first the team estimates the amount of work they can accomplish, then they task the work and have a sanity check.
- Daily standup – occurs every day at the same time. The team members share their progress since the last standup and report any blocking issues.
- Sprint demo – where the team demonstrates to the product owner the value they completed in the sprint. The product owner has final say on accepting the work products, or not.
- A retrospective where the team inspects the previous sprint and selects an improvement goal for the next sprint.
- Product owner – responsible for prioritizing and accepting the team’s work.
- Team – preferably 5 – 7 cross functional members so the delivered value can be deployed to production at the end of each sprint.
- ScrumMaster – coaches the team, helps remove blocking issues, shelters the team from outside distractions, makes sure the Scrum process is followed. A sample list of ScrumMaster duties: http://www.scrummasterchecklist.org/ // http://agilescout.wpengine.com/scrummaster-daily-check-list/
If it looks like a duck …
If you’re not following this process, and don’t have these roles in place, please don’t say “We’re doing Scrum.” You’re not. You may be following the agile principles, http://agilemanifesto.org/principles.html, and that’s great. But you’re not doing Scrum.
- [1/4] – The Agile Change Agent
- [2/4] – 3 Levels of Change Implementation
- [3/4] – Handling Resistance to Change
- [4/4] – Complexities of Attitudinal Change – Axiology
- C-Jump Game – Teach your kid how to program
- Agile/Life is hard. Press a button to make it all ok