We all need to have conversations, every so often, that can make us feel uncomfortable. Yet without these conversations it is hard to maintain interactions with colleagues and business partners.
Learning how to have these difficult conversations is a skill.
A good friend, Lydia Kan, is leading a workshop in Brisbane, QLD in a couple of weeks to help you understand better how to approach these conversations.
If you have the time and are in Brisbane I recommend you attend Lydia's workshop.
Find out more and sign up here
https://www.psychology.org.au/Events/EventView.aspx?EventID=13485
Showing posts with label Agile. Show all posts
Showing posts with label Agile. Show all posts
Monday, December 30, 2013
Saturday, July 30, 2011
Hardly any agile left in Agile
This is something has been nagging at my mind in the last couple of years. When I started getting interested in eXtreme Programming in 1998 it represented a step up from some of things I was already doing with software development teams. We were using techniques best classified as Rapid Application Development. First eXtreme Programming and then the Agile manifesto represented lightweight methods to get software shipped.
There are two important parts of that last statement:
1. lightweight methods
2. software shipped
The concept of doing the simplest thing to achieve a goal, is an important part of eXtreme Programming. Traveling light (or not carrying baggage from previous experiences) is an important part of being agile. One of the aspects of agile that I always found attractive was the objective of enabling the development team to deal with change in short time frames.
While it may not be fully apparent, from the behaviour of many software development teams, the objective of developing software is to ship a product, a finished piece of working software. This desire to find better ways to get software shipped is clearly not something everyone in the industry shares. that is why we have collections of rules that appear to do nothing than keep people in jobs. Don't get me wrong, I appreciate that in certain situations we need 5 people analyzing the business rules in order to determine how to build software that manages a complex business process. The reality I often see is that the business process is not that complex and the reason the team has 5 business analysts is because the career path for developers in that company is to be promoted to a business analyst role.
I digress...
The reason for this post is to try and make you think about how the actions you are taking are really making you more agile (small 'a'). If your objective is to be able to handle change with as little pain as possible then following a hard set of inflexible rules is not going to help you too much.
Shipping software is a art that is not easy to teach by laying down a set of rules, in many ways it is much more like a creative activity than an engineering activity. Decisions have to be made that are not pure engineering decisions, they are not pure business decisions, nor are the decisions purely design oriented. It is a combination of all of these things and more.
Questions that need to be answered include; is the software aesthetically pleasing to the user, is the software functional, is the time right to release this to the market, etc..
There seems to be this constant flow of software with rules designed to help people become Agile, there are also more and more people professing to have the ultimate rule book for Agile software development.
In my opinion this is 90% bogus, the number of people that have a career telling other people how to ship software and have not actually shipped software in years (or ever!) amazes me.
If you want to be truly agile then drop as many tools as you can, learn to do more with less rules and restrictions, and most of all practice shipping software by actually shipping software!
There are two important parts of that last statement:
1. lightweight methods
2. software shipped
The concept of doing the simplest thing to achieve a goal, is an important part of eXtreme Programming. Traveling light (or not carrying baggage from previous experiences) is an important part of being agile. One of the aspects of agile that I always found attractive was the objective of enabling the development team to deal with change in short time frames.
While it may not be fully apparent, from the behaviour of many software development teams, the objective of developing software is to ship a product, a finished piece of working software. This desire to find better ways to get software shipped is clearly not something everyone in the industry shares. that is why we have collections of rules that appear to do nothing than keep people in jobs. Don't get me wrong, I appreciate that in certain situations we need 5 people analyzing the business rules in order to determine how to build software that manages a complex business process. The reality I often see is that the business process is not that complex and the reason the team has 5 business analysts is because the career path for developers in that company is to be promoted to a business analyst role.
I digress...
The reason for this post is to try and make you think about how the actions you are taking are really making you more agile (small 'a'). If your objective is to be able to handle change with as little pain as possible then following a hard set of inflexible rules is not going to help you too much.
Shipping software is a art that is not easy to teach by laying down a set of rules, in many ways it is much more like a creative activity than an engineering activity. Decisions have to be made that are not pure engineering decisions, they are not pure business decisions, nor are the decisions purely design oriented. It is a combination of all of these things and more.
Questions that need to be answered include; is the software aesthetically pleasing to the user, is the software functional, is the time right to release this to the market, etc..
There seems to be this constant flow of software with rules designed to help people become Agile, there are also more and more people professing to have the ultimate rule book for Agile software development.
In my opinion this is 90% bogus, the number of people that have a career telling other people how to ship software and have not actually shipped software in years (or ever!) amazes me.
If you want to be truly agile then drop as many tools as you can, learn to do more with less rules and restrictions, and most of all practice shipping software by actually shipping software!
Tuesday, October 13, 2009
SyXPAC, Agile and time to change
Last night at SyXPAC I gave a short talk (lightening talk) on the last 10 years of Agile. The point of the talk was to say that Agile has helped raise the issues to the forefront of peoples minds but it hasn't really solved anything,
In software development we have seen cycles of approximately 10 years. In 1968 was the first NATO Software Engineering Conference, one of the aims was to drive the adoption of the practically unknown term "software engineering". The title of software engineering was decided upon to be deliberately provocative and spark discussion. At the time it did this and from this methods were invented to attempt to create predictability in software development cycles.
In 1980 the first version of SSADM (Structured Systems Analysis and Design Method) was released and the 1980's saw a far more rigorous approach taken to software development. In 1982 Roger S. Pressman released the first edition of Software Engineering, A Practitioners Approach. This book become the bible for software development methods and teaching.
In 1991 James Martin first proposed RAD (Rapid Application Development) as an approach to delivering software using a more light weight and iterative process. Other great authors such as Steve McConnell and Jim McCarthy adopted these ideas in different degrees and help publicize this new approach. In 1999 eXtreme Programming was first publicized, along with Kent Beck's book on the topic. Following this the Agile Alliance was formed and a collection of other agile approaches have been proposed and introduced.
From 2001 forwards the term Agile was used as a buzzword to ensure that what ever changes were made could be signed off by the big boss. A number of Agile methodologies were pushed in to the market, SCRUM, Lean, MSF agile etc... some good, some bad. Mostly they all missed the point that XP was a set of dev tools not a methodology, philosophy or religion. In many ways the Agile alliance, although good in theory, didn't help with this.
Recently I have noticed a new issue with Agile practices and specifically some of the XP practices. There has evolved a breed of Agile coach that has a 'do what I say not what I do' approach. This is with a valid reason. Many of the practices that XP preaches are really like scales when learning music or mental exercises when training the brain. As a developer becomes more adept at them they become embedded into the psyche of the activity and the props become less necessary. To the point that some really experienced developer can move away from the practices and deliver even more amazing software without noticeably paying attention to the core practices.
As it approached the chasm, like all things, XP got watered down to become acceptable to the stakeholders that need to buy in. I don't think that this watering down of XP actually hurt that much initially, it enabled XP to get a foot in the door. It was then up to the developer to implement the solution. Here-in lies the issue. Fundamentally most developers do not have motivation to improve the state of the industry. They need to get their paycheck so they can eat, be clothed and have a roof for themselves and their families. The real passion for most developers is not business focussed. The real passion is technology for the sake of technology.
Yet through all of these changes, the software industry has not improved its reputation for delivery of poor quality, over budget, bug ridden software. Each shift has brought some new thinking and new tools to the tool box of the software development team, yet the basic principles remain the same.
Back to the Point; Agile helps but it hasnt really solved anything, it is time for a change and we embrace change, right ?
In software development we have seen cycles of approximately 10 years. In 1968 was the first NATO Software Engineering Conference, one of the aims was to drive the adoption of the practically unknown term "software engineering". The title of software engineering was decided upon to be deliberately provocative and spark discussion. At the time it did this and from this methods were invented to attempt to create predictability in software development cycles.
In 1980 the first version of SSADM (Structured Systems Analysis and Design Method) was released and the 1980's saw a far more rigorous approach taken to software development. In 1982 Roger S. Pressman released the first edition of Software Engineering, A Practitioners Approach. This book become the bible for software development methods and teaching.
In 1991 James Martin first proposed RAD (Rapid Application Development) as an approach to delivering software using a more light weight and iterative process. Other great authors such as Steve McConnell and Jim McCarthy adopted these ideas in different degrees and help publicize this new approach. In 1999 eXtreme Programming was first publicized, along with Kent Beck's book on the topic. Following this the Agile Alliance was formed and a collection of other agile approaches have been proposed and introduced.
From 2001 forwards the term Agile was used as a buzzword to ensure that what ever changes were made could be signed off by the big boss. A number of Agile methodologies were pushed in to the market, SCRUM, Lean, MSF agile etc... some good, some bad. Mostly they all missed the point that XP was a set of dev tools not a methodology, philosophy or religion. In many ways the Agile alliance, although good in theory, didn't help with this.
Recently I have noticed a new issue with Agile practices and specifically some of the XP practices. There has evolved a breed of Agile coach that has a 'do what I say not what I do' approach. This is with a valid reason. Many of the practices that XP preaches are really like scales when learning music or mental exercises when training the brain. As a developer becomes more adept at them they become embedded into the psyche of the activity and the props become less necessary. To the point that some really experienced developer can move away from the practices and deliver even more amazing software without noticeably paying attention to the core practices.
As it approached the chasm, like all things, XP got watered down to become acceptable to the stakeholders that need to buy in. I don't think that this watering down of XP actually hurt that much initially, it enabled XP to get a foot in the door. It was then up to the developer to implement the solution. Here-in lies the issue. Fundamentally most developers do not have motivation to improve the state of the industry. They need to get their paycheck so they can eat, be clothed and have a roof for themselves and their families. The real passion for most developers is not business focussed. The real passion is technology for the sake of technology.
Yet through all of these changes, the software industry has not improved its reputation for delivery of poor quality, over budget, bug ridden software. Each shift has brought some new thinking and new tools to the tool box of the software development team, yet the basic principles remain the same.
Back to the Point; Agile helps but it hasnt really solved anything, it is time for a change and we embrace change, right ?
Thursday, June 18, 2009
Your child is ugly!
I was recently asked what tools a team should have to support SCRUM.
- As many big whiteboards as you can make space for in the developer area
- Lots of whiteboard markers, never be in a position where it is hard to find a marker
- Open communication channels.
- A developer ego extraction utility ( this is the hardest tool to find IMO)
- A developer passion insertion tool ( somewhat easier to come by)
4 is important, let me expand on this.
Software creation with passion becomes very personal, the creation is a child of the developer. Flaws found and pointed out in peoples children are often not taken well by the parents. Developers often take suggestions for improvement very personally because they see it as an attack on their ability.
The product created needs to be an output of the team. A team that works great together will deliver great software. Often the weakest part of a team is the team member with the biggest ego. If you find you have a team where certain members of the team are not performing as well as they could it be, you often find the ego of another team member blocking their growth. The team member that wants to be the hero in the team is commonly blocking the growth of others, as it helps them feel more important.
Tuesday, May 06, 2008
SyXPAC lives!
Last night I headed down towards Darling Harbour to the regular SyXPAC meeting.
I started Sydney's eXtreme Programming Activity Club at the end of 2001 as a way to spread the knowledge about eXtreme Programming. Initially a monthly meeting, it has gone through many phases. The hardcore SyXPAC members meet weekly on Monday evenings, drink, eat and discuss software development.
At last nights meeting we discussed how SyXPAC can enter a new phase and become interesting to new people interested in finding out more about agile development and learning to build better software.
It sounds like there will be monthly SyXPAC events focused around presentations, discussions and debates. If you have topics you are interested in then you should get involved and put a request in the SyXPAC blog or on the Yahoo! group.
I started Sydney's eXtreme Programming Activity Club at the end of 2001 as a way to spread the knowledge about eXtreme Programming. Initially a monthly meeting, it has gone through many phases. The hardcore SyXPAC members meet weekly on Monday evenings, drink, eat and discuss software development.
At last nights meeting we discussed how SyXPAC can enter a new phase and become interesting to new people interested in finding out more about agile development and learning to build better software.
It sounds like there will be monthly SyXPAC events focused around presentations, discussions and debates. If you have topics you are interested in then you should get involved and put a request in the SyXPAC blog or on the Yahoo! group.
Wednesday, June 06, 2007
TechEd 2007 Orlando
Day 2 of TechEd already!
Catching up with lots of people and my decks and demos are nearly finished.
It was interesting to see Agile given so much time in the keynote yesterday, and the Agile .NET session yesterday lunch time was packed out.
I am talking to lots of people who say they are getting value out of the event which is good.
There is, of course, a lot of marketing hype and BS around as well. It amazes me that peopl eactually believe that buying a software tool/product/plugin/component will make them better developers.
As I pointed out at the Agile .NET session, delivering great software is about sticking to values, not applying practices or using tools. The practices are only there to help you stick to the values, and if the practices don't do that then you need to change them.
Catching up with lots of people and my decks and demos are nearly finished.
It was interesting to see Agile given so much time in the keynote yesterday, and the Agile .NET session yesterday lunch time was packed out.
I am talking to lots of people who say they are getting value out of the event which is good.
There is, of course, a lot of marketing hype and BS around as well. It amazes me that peopl eactually believe that buying a software tool/product/plugin/component will make them better developers.
As I pointed out at the Agile .NET session, delivering great software is about sticking to values, not applying practices or using tools. The practices are only there to help you stick to the values, and if the practices don't do that then you need to change them.
Subscribe to:
Posts (Atom)
