Three Secrets to Building Your Influence, Part 2, Trust If you want to change anything in your organization, you need to influence at least one other person to succeed. I wrote about competence in Part 1. This part is about trust. How do people trust you? They might expect you to be predictable in two ways: […]
Back when I was a manager, my senior management wanted to separate the “new” work from the “maintenance” work. I suggested that every new line after the first line of code was maintenance. The managers poo-poohed me. My concern: How would the “new” developers learn from their mistakes? I lost that discussion and I managed
In my experience, too many projects are under too much pressure. The sponsors want all of the features, completed in too-short time, with no defects. And, if possible, the sponsors think the project should cost nothing, the team should not need any training, and the team can work in any way, regardless of the desired
Three Secrets to Building Your Influence, Part 1, Competence If you want to change anything in your organization, you need to influence at least one other person to succeed. Mary, a leader in the organization, wanted to help her colleagues consider a variety of agile approaches. The organization had chosen a framework, and the framework
I wrote about how to pick a driver in Part 1. In Part 2, I wrote about how you might finesse some of the constraints and floats if you can release frequently. What if you’re like this organization, Acme? Acme has been working towards agility for the last couple of years. However, they still have
In Part 1, I wrote about the origins of drivers, constraints, and floats. I needed them when we only could release the project once to the customers. You saw the questions that help people choose the project driver. What about the constraints and floats? I think of constraints as bounding the project inside the driver,
Do you know your project’s bounds? Do you know what your sponsors want from your project? For many years, I heard about the “iron triangle.” Sometimes, the triangle was “Scope, Quality, Cost.” Sometimes, it was “Scope, Date, Cost.” It was always three things out of a minimum of four possibilities. I never saw a triangle
Do I advocate insubordination? Some of my Modern Management Made Easy technical reviewers wonder. And, when I looked at this definition of insubordination, I had to agree. However, when I read that definition, I don’t see any mutual problem-solving. I also don’t see any mutual purpose or respect. I don’t see how that form of
I’m delighted to announce I published the Conference Proposal book! I collated all the conference proposal posts into a book. And, I added more content only available in the book. The book is through copyediting. You can buy it on Leanpub now in all electronic forms. Yes, I will upload the book to all the
In Costs of an Agile Approach for Hardware Products, I suggested that an iteration-based approach for hardware was too expensive. I focused on the actual development costs. Let me talk a little about the team and alternatives here. What Does a Hardware Team Look Like? Agile software teams are cross-functional and interdependent. The team is