Menu

AdamM

About AdamM

https://ouragilejourney.com

I have been a software developer since June 2008. Before that I spent almost 5 years working my way from part-time computer support to Systems/Network Administrator & IT Team Lead of a 500 person multiple campus company. Before that I did 2 years as a phone support technician. With over 12 years of IT industry experience spread across both system administration and software development I see IT in a broader scope than most. Now I am becoming something more. I am an Agilist. I am moving on to project management. I am pushing positive change within my team, group, and company. I am looking to provide the best solutions for delivering the most value to organizations in the shortest practical time. I believe that even as I move from implementing Agile to teaching Agile to others I will never be done learning it.

Posts by Adam Myhr:

Our Agile Flavor

, 0

Our team is running a little bit Agile in a company that likes requirements up front. We are also doing this as a bottom up shift in thinking.

As previously stated most of the software on our team is in maintenance mode. We are still running our last re-write as a project. It could easily be considered in maintenance, but that has not changed how we work it. Our newest re-write is just getting into full swing. That one is where we are trying hard to run it as an Agile project instead of the mostly stage-gated waterfall that we did before. It remains to be seen how well this works for us. It can be said now that we are using Agile practices on both of these projects.

The project manager and I do have a goal to be as Agile as possible. We aren’t doing this just to make ourselves feel good. We want to deliver the best value to our users that we can as quickly as we can. We are trying to learn from our previous project, which has had some pretty decent re-work, and apply that to this next one. Our conclusion has been to try and run Agile.

More

Agile Without a Project

0

Projects have a start and finish. For most software projects the project is considered finished either right before or right after it enters maintenance mode. Most of our applications are running in a maintenance mode and have been for a long time. Requirements for these are generally done as feature requests or bug reports. Running maintenance mode in an Agile manner is going to look different from running an actual Agile project.

If we were running the support desk in addition to being the development team I would have us model our maintenance projects after Kanban. The layout would consist of the developers pulling items in from a story collection. This collection would be ordered by the product owner much as the backlog currently is. Hot ticket items from the floor would be dropped into the top of the list.

More

Trimming Meetings

, , 0

The changes to our estimation process have been a huge hit. The project manager has been nothing but pleased with the new methods. She used to fear estimation meetings and no longer does. The team all has an idea what is happening now when previously they did not. The business feels they have a better handle on what we can get done in any given amount of time. It has been a good fit all around. With this initial success it was time to look at what else in our process could be improved within the limitations we have to endure.

As a by-product of a failed Scrum implementation a few years ago we work in two-week sprints and have daily status meetings. We had a lot of other meetings though. There was a planning meeting that was attended by one developer, one person from SQA, and both business analysts. (In fairness, one of them is the project manager as well.) These meetings were long and painful for everyone involved. They went through the requested work trying to define what exactly it was. They picked what would be done next. They broke it down to tasks and times after which they assigned it to a person. After these meetings would be another meeting we called a kickoff in which the whole team was invited.

More

Original Estimate. Remaining Work. Completed Work.

0

These have been the three most underutilized and ignored fields in our TFS template for over two years. We did an entire application re-write with three major release milestones, multiple integration points, and multiple small maintenance releases hardly acknowledging these fields. What little estimation data the project manager received was from one person on the team. Actual information was never fed back in. Estimations were broken. It was increasingly difficult for the project manager to reliably communicate with the business what the team could accomplish at what time. This was the biggest pain point we could identify.

Our bottom up approach to Agile implementation started here. As long as upper management received time based estimates on features for Enterprise planning purposes they were not especially concerned with where they came from. They cared only for how accurate we felt they were and how accurate they ended up being. That mindset allows us to change our estimation methods with little fear of interference. This is likely a common state for a project team to be in.

More
Agile Estimation and Planning

Agile Estimation and Planning by Mike Cohn

0

Agile Estimation and Planning

I have to start by admitting that I purchased this in the Kindle edition. This was very convenient when I was initially reading it. However, now that I have completed the book I wish I had the physical copy for quick reference.

I would buy this book again, and suggest it to others. Mr. Cohn describes it as a book about planning which includes the background in estimation as planning without estimation is impossible. He also points out that the title was very intentional. To have a successful Agile project your planning and estimation must also be Agile. My focus for this book was on the estimation front. I also used it as a reference for my PMI-ACP certification. It is nowhere near a complete reference for the certification, but was never intended to be. In the realm of moving our estimations forward it was a great help. Most of what we currently do for estimation can be traced back to what I learned from this book. If you are interested in knowing simply what each section of the book is about the Introduction is very well written and will tell you exactly what you want to know. In light of this I will be covering what I took away from it in a little more general sense, showing where I found value.

More

Estimation is hard. Part Two.

0

I covered the three main reasons I use Planning Poker last week. This week is about how planning poker plays out in an estimation meeting.

The best way I can think of to see how planning poker works is to show it. The estimation will be for a trip from Minneapolis to Chicago. The Product Owner has called her group of developers together to provide an estimate for the customer. The developers are all the people who will do the work on the trip. An analyst might be used to better define the trip parameters. A developer may be used to build the trip based on the parameters, but usually there will be more than one. Someone else may be testing a model of the trip to ensure it satisfies all parameters to the best of the teams ability. The people involved may or may not know a lot about the other roles present. For this exercise the important thing is that each person doing work for the requirement is present to estimate it.

More

Estimation is hard. Part One.

0

How long does it take to travel from Minneapolis to Chicago?

Give a group of ten people this question and ten answers will come back. Some may be radically different. People have a lot of trouble estimating how long something will take, or how big something is. I see this in my own life on almost a daily basis. How long will it take to change the brakes on the car? On the van? Cook dinner? Each time I think it will take a different amount of time, and each time it does – but I am still wrong about how long.

This is a problem when a business is trying to plan enhancements and future projects. The good news is that while we are bad at straight time estimation, we are usually pretty good at relative estimation. The brakes on the van will take a little longer than on the car due to the size difference of the vehicles. Dinner today will be quicker than yesterday’s because of the dishes I am making. A trip to Chicago might take twice as long as a trip to Ames, but it could be half the time as well.

More

Gaining Buy-In

, 0

Doing Agile from the bottom up as an internal team is very different then having an external coach brought in by the organization. As our Agile Journey starts it needs prioritization. Not the product backlog, the Agile implementation. Changes have to start small. They are gradual and can only impact this team. For maximum effectiveness benefits are as far-reaching and highly visible as possible. Success or failure is in full view of the organization. Knowledge, planning, passion, and teamwork will stack the deck in favor of success. Success breeds buy-in from above.

To do this alone would be nearly impossible. On a team of four developers I am the most junior. While my overall IT industry experience is on par with the rest of the team, they spent all of it in development roles. For me it has been just under half, with the non-development experience at a different company. Our project manager was let go at the beginning of the year. I was not yet in a position to take on the role and it was given to our lead BA. There was a catch. It become a dual role of lead BA and project manager. This was already a stretch role. The knowledge gained while earning my certification gave authority to my offer of help. The pending maternity leave of the other BA made the need for help painfully obvious.

More

Agile Certification In Use

0

At the end of April I became certified in Agile Practices by the Project Management Institute. There is nothing magic about a certification. What the PMI-ACP does for me is show that I have experience in Agile practices, gained enough book knowledge along the way, took an official Agile Methodologies class, continue to learn more via approved learning methods, and care enough about all of it to spend money showing the accomplishments. While that last one is technically true it is not exactly proven by the certification. In fact, my employer reimbursed me for both the class and test. (In my defense I only learned that this would happen after I committed to making it happen.)

What does matter is what happens next in my professional life. How do I use this in my career?

More

PMI’s PMI-ACP

, 0

Many of us have heard the terms Agile and Scrum. If you have a similar background to me then you have heard them largely as a way to build software in a team environment. Established in 2011, PMI’s Agile Certified Practitioner certification looks beyond the confines of specific methodologies and past the boundaries of software projects and shows how they can benefit many types of projects while using any number of tools. I took an online course to prepare for the certification exam. While software development was the target for the majority of the course I took, there was an effort to point out that the methodology, and some specific tools and techniques, could apply to other types of projects.

More

Load More