Lean, Agile, Scrum, Kanban.
They are all approaches/methodologies for doing what we all agree is important for our industry to move forward to a more effective approach to getting our products done faster and with more quality and value.
That being said, why do we in the community keep attacking and denigrating each other's practices for achieving these goals? Are we really so petty? We are all working to the same goal. We want to build good software. We want to use tools that help us to get it done. We want the minimum interference to completing our work.
TDD is good, TDD is bad. ATDD works, ATDD doesn't work. You need to do Scrum, no you need to use Kanban.
Let's face it, these are all tools in the toolkit and not all tools are needed all the time. You pick and choose what is needed for the particular task at hand.
Quit maligning each other.
Agile has become a mainstream buzzword and once things become mainstream they are inherently more visible. The ideas underlying the original definition of the Agile Manifesto is getting lost in all the religious wars. As such, we are allowing ourselves to get sidetracked from doing the job right. And by right I mean with business value, high quality, maintainable, with an ability to plan for the future without overbuilding.
- JMH
Tuesday, September 15, 2015
Escalation?
Normally an agile team takes responsibility for getting things done into their own hands. In the best case its a DevOps scenario and you have embedded folks who have all the skills and access required to tackle the non-code issues that will arise in a project/product/program.
If the database is down the DB folks will log in, make the required changes, script the fix for higher environments and roll it along.
If the server has issues the Linux dorks will login, clean things up, script it for other environments and rinse and repeat.
But what do you do when you are an agile bubble in a waterfall world?
That is when things get more difficult. Assuming you have the ability to even access the DB or the server odds are quite good that you won't have the correct permissions. More likely you can't even get in. In this scenario you are dependent on an external team. Who may have other priorities. And be matrixed across many projects. And they don't understand your urgency. After all, its just a Dev server, right?
Well now it sucks. You can call/email/IM them about the problem. Better yet you can walk down and discuss it. They maybe even take care of the issue for you.
Hurray! Back in business.
Until the problem happens again. And again. And again. I'm not loving this game.
See the thing is that they are clearing the immediate problem but not addressing the longer term issue. So it keeps happening. And you keep talking to them and they keep quick fixing and blah, blah, blah.
I understand. Their priorities are different and I am not the primary responsibility. But after a few trips down you would think we'd all be tired of this game and the problem would have a long term fix. Does it sound like the 90s all over again. Of course not because back then we wouldn't even know about the issue until three months later when everything is due and we are manually jamming it into prod.
Ah the good ole days....
Anyway, how do we, being agile, deal with a problem that can only be fixed by a waterfall person? Well, we discuss it with the folks down there (up there, wherever) and explain the longer term problem. When that doesn't work we need to start escalating.
That means the scrummaster and the PO get notified. Scrummasters remove impediments and POs want there stuff done so they can raise it to whomever they need to. So now we are pushing things up the org chart so it can come back down the other lane in the org chart so that a fix can get implemented.
The thing is that there doesn't appear to be a better solution. We need paper trails and risk statements and some potentially bruised egos just to get what seems to be a logical solution to a recurring problem where two different groups work in completely different models.
No one said things would be easy. But when you are banging into waterfall there aren't many other solutions.
DevOps would be nice. But that isn't always possible and then we are left with some old world tricks.
Sunday, August 14, 2011
WTF People?
I have two young children, currently six and seven, and I am depressed and anxious for their future.
Part of the anxiety is the general tone of the politics in the United States these days. I don't believe in the "good ole days" but the posturing, finger pointing, partisanship, and blinding need to get reelected is so disheartening. Politicians work to stay in office harder than to represent constituents and even when they try to act in what they believe are our best interests it's so mired in inflexible dogma that the concept of compromise is a joke. What happened to the Republic we were promised by the founding fathers? Ben Franklin had it right when asked what kind of government the founding fathers gave us he responded "A Republic, madam, if you can keep it." We have lost the republic to "mob rules", sound-bite driven democracy we currently have.
Nations as a rule are following economic policy that no one would imagine using in their own homes but they seem to believe is fine on a macro level because, you know what, they probably won't still be in the same political office when it hits the fan.
We also have a planet that is beginning show signs of cracking. I'm not going to spout statistics about global warming or other numbers and such, but the threat of global warming certainly is part of my anxiety. You may not agree with our level of influence on global warming but you cannot dispute the Great Pacific Garbage Dump. That's all ours and it has nothing to do with nature's cycles. We have become a consumer driven, wasteful nation. No where is this more evident than with the toys I have had to unwrap for my kids when they get gifts. Eight feet of wire ties and tape later I can hand a barbie to my daughter. Then I'm left with a giant pile of cardboard and plastic that I hope gets recycled when I put it in the recycle bin. There is more to life than stuff but even the little bit of stuff I buy is 80% waste and marketing.
With all that how do I look at my children and their future and not be depressed and anxious?
- JMH
Part of the anxiety is the general tone of the politics in the United States these days. I don't believe in the "good ole days" but the posturing, finger pointing, partisanship, and blinding need to get reelected is so disheartening. Politicians work to stay in office harder than to represent constituents and even when they try to act in what they believe are our best interests it's so mired in inflexible dogma that the concept of compromise is a joke. What happened to the Republic we were promised by the founding fathers? Ben Franklin had it right when asked what kind of government the founding fathers gave us he responded "A Republic, madam, if you can keep it." We have lost the republic to "mob rules", sound-bite driven democracy we currently have.
Nations as a rule are following economic policy that no one would imagine using in their own homes but they seem to believe is fine on a macro level because, you know what, they probably won't still be in the same political office when it hits the fan.
We also have a planet that is beginning show signs of cracking. I'm not going to spout statistics about global warming or other numbers and such, but the threat of global warming certainly is part of my anxiety. You may not agree with our level of influence on global warming but you cannot dispute the Great Pacific Garbage Dump. That's all ours and it has nothing to do with nature's cycles. We have become a consumer driven, wasteful nation. No where is this more evident than with the toys I have had to unwrap for my kids when they get gifts. Eight feet of wire ties and tape later I can hand a barbie to my daughter. Then I'm left with a giant pile of cardboard and plastic that I hope gets recycled when I put it in the recycle bin. There is more to life than stuff but even the little bit of stuff I buy is 80% waste and marketing.
With all that how do I look at my children and their future and not be depressed and anxious?
- JMH
Wednesday, March 24, 2010
Roles in Agile
What are the common roles on an agile team? Agile developer, agile tech lead, agile delivery lead, QA? Many of you will recognize these titles, many have filled one or more of them.
Team roles are something that are prescribed by some methodologies and sometimes they evolve on the team. Other times they are simply appointed because it feels natural to have them.
Over the years I have filled a few of these and in most instances the roles imply a set of responsibilities that differentiate them. I have thought about these roles when I have been in them and wondered lately why they have to exist.
The current client I am engaged with is in the midst of an agile transformation and the teams that have been created have been structured as Scrum teams with all of these roles accounted for. The teams have various levels of success with the transformation, mostly pretty good.
What I have come to realize is that the roles are an illusion.
There isn't any one particular role that one team member holds that can't be distributed across the team as stories. Admittedly, different team members have different skills and abilities that influence the level of success that each member would have taking on these stories. However, these differences should be mitigated with solid pairing and mentoring and would, over time, develop all of the team players to take on the tasks normally assigned to a role without requiring a particular person executing them exclusively.
The structure of the teams have been configured as they are to impose structure to allow a level of comfort to the players involved as they became knowledgeable in the discipline of being agile. The intent is that the structure will be stripped away in time while leaving the responsibilities with the team.
Whether that means the roles remain with the same people filling them is an open question. I believe that the roles themselves can melt away or effectively become hats that different team members wear on any given day.
Personally I prefer the latter option. I think the team as a whole will be more nimble and be able to adapt to change much better than if the names remain the same. If all team members have handled the responsibilties over time, with a self-organizing, revolving door, then the loss of one member due to illness, outside change or simple evolution, the team ownership of the product and process is stronger and the commitment is stronger. I also believe the quality of every person on the team will be higher than would otherwise be the case. All of this means the product is better, the team is better and consequently the organization is better.
What do you think?
Team roles are something that are prescribed by some methodologies and sometimes they evolve on the team. Other times they are simply appointed because it feels natural to have them.
Over the years I have filled a few of these and in most instances the roles imply a set of responsibilities that differentiate them. I have thought about these roles when I have been in them and wondered lately why they have to exist.
The current client I am engaged with is in the midst of an agile transformation and the teams that have been created have been structured as Scrum teams with all of these roles accounted for. The teams have various levels of success with the transformation, mostly pretty good.
What I have come to realize is that the roles are an illusion.
There isn't any one particular role that one team member holds that can't be distributed across the team as stories. Admittedly, different team members have different skills and abilities that influence the level of success that each member would have taking on these stories. However, these differences should be mitigated with solid pairing and mentoring and would, over time, develop all of the team players to take on the tasks normally assigned to a role without requiring a particular person executing them exclusively.
The structure of the teams have been configured as they are to impose structure to allow a level of comfort to the players involved as they became knowledgeable in the discipline of being agile. The intent is that the structure will be stripped away in time while leaving the responsibilities with the team.
Whether that means the roles remain with the same people filling them is an open question. I believe that the roles themselves can melt away or effectively become hats that different team members wear on any given day.
Personally I prefer the latter option. I think the team as a whole will be more nimble and be able to adapt to change much better than if the names remain the same. If all team members have handled the responsibilties over time, with a self-organizing, revolving door, then the loss of one member due to illness, outside change or simple evolution, the team ownership of the product and process is stronger and the commitment is stronger. I also believe the quality of every person on the team will be higher than would otherwise be the case. All of this means the product is better, the team is better and consequently the organization is better.
What do you think?
Sunday, March 21, 2010
Polyglot Programmers
Do you have a favorite programming language? Most developers do. Sometimes it's the first language they learned. Sometimes it's the first one they became proficient in. In many cases programmers who have a favorite language may end up favoring it and in time they end up only writing code/applications in that given language. Other times a developer may just get in a rut or habit and continue down a path with a language because it is comfortable and they feel confident working with it.
There is a problem with this approach to development.
This situation leads to a myopic view of coding and design that can limit your options when building. It is a familiar scenario mostly commonly expressed as "When all you have is a hammer everything looks like a nail." You look at every problem as a Java problem. Or a C/C++ problem. Or Ruby.............
You can see where this leads. A programming language is a tool. Nothing more. Ask a carpenter what the best tool in the toolbelt is and they will ask what you are trying to do before they answer. It's an obvious question to ask - you can't say the best tool is a file when you need to screw a doorknob to a door.
But ask a bunch of developers what the best language is and they will nearly all have an answer. Even without asking what you are trying to do. That is a problem that many developers miss.
Every programming language has it's good and bad. There are things that some languages do quite well where others struggle and vice-versa. I will refrain from stating these pros and cons to avoid the common arguments that arise as it is beside the point.
Good developers know that it is important to have many tools in the box to address the different problems they are going to have to solve and they will work at getting and staying proficient with the tools available so they can recognize when one tool fits the problem at hand better than another.
I try to keep abreast of the cool languages out there. There are always new ones to look at, old ones to refresh on, and off-the-wall ones that are just neat to play with. Some you may never use, others will get broken in daily but it is important that you have as many tools at your disposal as possible so you can build your solutions to the best of your abilities.
Another reason to learn lots of languages (as well as IDEs, compilers, platforms) is because exposure to different programming languages exposes you to different viewpoints and approaches to solve problems that you would not have were you not experimenting.
I aim to be a skilled craftsman and every skilled craftsman knows what is really important with tools. Keep them clean, keep them sharp and keep them within reach for when you need to pull them out.
There is a problem with this approach to development.
This situation leads to a myopic view of coding and design that can limit your options when building. It is a familiar scenario mostly commonly expressed as "When all you have is a hammer everything looks like a nail." You look at every problem as a Java problem. Or a C/C++ problem. Or Ruby.............
You can see where this leads. A programming language is a tool. Nothing more. Ask a carpenter what the best tool in the toolbelt is and they will ask what you are trying to do before they answer. It's an obvious question to ask - you can't say the best tool is a file when you need to screw a doorknob to a door.
But ask a bunch of developers what the best language is and they will nearly all have an answer. Even without asking what you are trying to do. That is a problem that many developers miss.
Every programming language has it's good and bad. There are things that some languages do quite well where others struggle and vice-versa. I will refrain from stating these pros and cons to avoid the common arguments that arise as it is beside the point.
Good developers know that it is important to have many tools in the box to address the different problems they are going to have to solve and they will work at getting and staying proficient with the tools available so they can recognize when one tool fits the problem at hand better than another.
I try to keep abreast of the cool languages out there. There are always new ones to look at, old ones to refresh on, and off-the-wall ones that are just neat to play with. Some you may never use, others will get broken in daily but it is important that you have as many tools at your disposal as possible so you can build your solutions to the best of your abilities.
Another reason to learn lots of languages (as well as IDEs, compilers, platforms) is because exposure to different programming languages exposes you to different viewpoints and approaches to solve problems that you would not have were you not experimenting.
I aim to be a skilled craftsman and every skilled craftsman knows what is really important with tools. Keep them clean, keep them sharp and keep them within reach for when you need to pull them out.
Subscribe to:
Posts (Atom)
Posts
