My last post was laid out the basic parts of how I think about agile coaching. This post will take on the first piece which is: You.
There are incredible people in the world that have taken up the profession of agile coaching. There are others, like me, who are figuring out what to do with their passion. Others still, are trying to make a buck by riding a wave of the current trend.
You have heard, “Change is hard,” before. There may even be a personal experience that you have where these words were true. Here are my thoughts on those three words.
I finished my most recent coaching engagement three weeks ago. This team watched another one go through a transformation for the eight months prior.
Last week, during stand up a manager that I’ve been working with said, out of the blue, that several work items now have a deadline of the next Wednesday. My ears perked up.
There is enough written about effective and more so ineffective stand-ups. This time I want to explore the idea of what happens after a stand-up is over.
Early in my career constraints were something that filled me with dread. They spoke only to what I could not do. They held me back. They left me bound and unable to see a path forward.
Testing software isn’t a new subject by any means, but that also doesn’t mean it’s well understood or easy to approach. If you’re starting a new project you have the benefit of only needing to test what you create, but if you have an established, legacy project you have the extra burden of trying to test the other interactions of code and system that already exist.
In my previous life as a developer, I would get asked to stay late and work. This happened for only two reasons:
I want to try and commit a little heresy by talking about story point estimations. Specifically I want to talk about not using them ever again. This is not a call for no estimation, but a fairly different approach. This idea has some problems, is not fully fleshed out, and needs lots of smart people to think about.
I remain an uncertified agile coach. I wish to continue to remain an uncertified agile coach. I have missed many opportunities because of this position.
If great teams deliver great products, what do poor teams deliver?
Sex is pretty great. Most people of a certain age tend to agree on that point. STDs are not great. Most people agree on that too. Software tends to be a little bit of both.
If we are using Scrum as the foundation for our agile process, then we have a Product Owner who is out there discovering and prioritizing the things that continually deliver increasing value to the business and it’s customers.
Companies have to be careful about the costs that they incur. They have to in order to stay in business. This cost-consciousness, can be described in one of two ways, cost as a concern and cost as a constraint.
We all love throwing around, “High-Performing,” teams as something that you get when you transition to agile beliefs and practices. This high-performing team could be described many ways, and I’ll try to provide a way to think about the journey a team takes as they become high-performing.
Scrum Masters are farmers whose seeds are employees and whose crops are people.
Every software developer and engineer I’ve ever worked with, myself included, has remarked at how romantic it is to do yard work.
I thought I’d try something a little ambitious and catalog activities that can help people in their endeavors to be better entrepreneurs. So the first activity I’ll write about, I will call, “Say Yes.”
I think most people in software are familiar with the daily stand-up meeting. Everyone literally stands up and then goes around the room answering three basic questions:
I am a big believer in system thinking. This can be pretty simply defined as believing that people are doing the best that they can, and that the system they are required to operate in is what dictates the results. Another way of looking at it is realizing that if you put any person in the same situation in a given system, you will almost always get the same results.
A really good friend of mine was visiting and we were just catching up. We were talking about what things we have been doing with our time and we both surprised one another by saying that we have both taken an interest in Fly Fishing.
The title of this post is a parody on the infamous For Sale: Baby shoes, never worn. It is an example of what is sometimes called, “Flash Fiction.” While the title of this is a parody, it has remained a work of non-fiction in many of the organizations I’ve been in.
Everyone I work with and know has a grand idea for a business or product. I like to ask them lots of questions about their idea to see how much they’ve thought through. It seems most people have constructed a fairly detailed fantasy about their idea being wildly successful.
Sometimes, I get a lot of pressure from clients to build more and more features. There are plenty of people who speak on the perils of, “The Feature Trap.” I wanted to try and work out my own way of explaining it, and thought I would share where I wound up after thinking about this for a 5 hour car ride home.
Lets go over some basics when working with software freelancers, contractors, and agencies. If you’re not new to software or these kinds of groups, this is probably going to be pretty pointless.
I’ve been in a lot of organizations that in their adoption of Scrum, they transition project managers to becoming product owners. This is a trend I continue to see, and I thought I’d explore some of those common trends here.
There is an endless number of questions that plague any group releasing a product, but there is one that, if ignored, will cripple any chance of success, and if answered, can yield phenomenal results.
If you've got questions about what's here or my services, please email me.
© 2015 Ryan Latta
Original design by Rick Waalders