Note: this text was written some two years ago and somehow it was never published. Publishing now in order to have a reference point for further posts.
Measuring software is something that I've been wondering for quite some time now. Nobody measures software as such, only it's internal or external side effects. These observations are then analysed and some conclusions are drawn out of those. In most systems the interactions are so complex that it is argued that software measurement is considered as necessity.
I had a interesting exchange of ideas the other day. Would there be a measure that would tell us is our software good or bad. Without doing any traditional testing. Can we just look at the software, running, and say "this is good" or alternatively "this is bad, not sufficient". The conclusion we drew was that no, we need to still inspect the software's side effects (do testing) and then determine if software is ready to be deployed or not.
I am sure that there has been several scientific articles written about how to measure software from the point of view of completeness, functionality, applicability, unwanted functionality and so on. I am not going to even try to challenge these in any way here. I believe that they are necessary tools to determine the state of software.
What I am after is the holistic set of tools and methods that could be used to make those determinations. Something that we could use in our daily work to create software systems that would actually satisfy users expectations.
Software theory teaches us that by applying the V-model you get satisfactory software most of the time. I bet that can even be proven and probably has been. Why then, according to my observations, there can be so much of substandard software around and in use? Is testing really seen as unnecessary investment of time and resources? Is it impossible to apply in all cases? Is it purely the business reasons that force people and companies to release unfinished software?
Applying theory to practise is difficult because the theories don't take into account the true complexity of real world situations. Theories work on models that make assumptions about the reality but quite often the modelling leaves out details that will break the applicability of that theory in question.
Despite that the management of software relies on those models and insists that they must be applied. If the methods produce data that supports determination that the software is indeed defective then that becomes the truth. That truth becomes dogma. Game is over.
lauantai 15. joulukuuta 2012
Doing UXD with Scrum - an experience report
I recently saw a Tweet from Özlem Yüce (@OzzieYuce) calling out for books or blogs that talk about mixing UXD with Agile and Lean. As I have been doing that from time to time I though I write something down.
The last project I did where UXD was involved was a short device project. We started this in May 2011 and the project ended on June 2012. We spent quite some time in doing market and customer research before setting up the development teams for software for this product program so it was not until fall 2011 we got some UXD people on board. At that time we were doing different alternative designs and some quick prototypes to get material to use in the deep dive interviews and market research we wanted to do with real mockup devices. That gave us the initial vision on the UX for the device and in the beginning of 2012 we got first SW teams set up.
For the UI framework and apps SW setup we decided to use Scrum. We coupled UXD tightly to the SW cycles and as often happens the initial sprints were done without UXD that was to be final. This was the whole point of doing things in Scrum: we start with something, see how it turns out and make informed decisions what if anything to change.
The team location setup was not ideal. The Development Teams were in Oulu and the UX designers were sitting in Espoo. To reduce risks related to Dev Teams and UXD not being co-located we got into practise to get the UXD team members visit us in Oulu and to do joint Sprint Plannings. After few Sprints in this fashion we converted to having the UXD team join in our planning session via teleconference. This proved to be somewhat suboptimal as the discussion was difficult to follow for those sitting in Espoo and they did not have much to contribute to the overall discussion about User Stories.
After few sprints the UXD had enough of design ready to be handed over to the Development Team. The team took the designs and tried to realize it with SW during a sprint. Quite often the SW turned out to be not as expected as the written specifications left quite much things open and then we had to rework the software in the next sprints. In effect, we were doing somewhat mini-waterfallish Sprints. It was pretty clear to me that this was due to lack of common understanding of what the details of the UXD was and how it was fitting together in the big picture.
Clearly this was not working as Scrum should. The things were not getting done. To help the situation I tried to pull the UXD team to work in concert with Dev Team in Oulu. This was unfortunately not possible. We thought of using Skype or some other personal video conferencing system. Those were not working for a reason or another. Then I decided to bluntly go against the rules and started booking our expensive but awesome tele presense system so that we could get all of UXD people and relevant Dev Team members to discuss open things and keep their common understanding better in sync. You may think that Skype would work just as well but there is not really any comparison. The telepresense system is a studio with negotiating table and four huge flat screen TV:s where the other side of the "table" is visible in natural size not to mention live-like sound quality. You just can't get this with a webcam and a headset. Using this system helped a lot. The designs could be discussed, things in progress could be demonstrated on live devices via the table camera and solutions to design challenges were quickly discovered. We tried to have at least 1 hour slot reserved for this each day. We set it up in a open space manner. Time was communicated to all and people could just walk in and see who was there and increase their understanding what was happening at the time in both locations.
In general the UXD and Dev teams were happy. UXD was particularly happy about the fact that they had very early live devices that had always working software available to review the software and communicate their views back to SW devs each day. Although some of the UXD was designed before the actual Sprint where it was to be realised this kind of daily opportunity was the key element for success. I dare to call this a success despite this could have been going even better if the working culture of the UXD team would have allowed for "unfinished" or "unpolished" designs to be floating around for Dev Team to pull in and do working software that was in the end the only measure of success.
We managed to deliver quite polished looking software for the consumer studies that were done with real devices. I am very proud to say that the software was also fully functional and well performing on the actual devices. It was so well functioning that the customers we showed the device to never suspected that it was just a "prototype" with minimal functionality. Not really a prototype but an increment of working software that was planned to be iterated upon several Sprints more. In the end that was not to happen. Stephen killed this product along with some others in June 2012 and that had career impact to me and many of my colleagues.
I will return to this topic "How to do UXD in Lean/Agile way" in the future.
The last project I did where UXD was involved was a short device project. We started this in May 2011 and the project ended on June 2012. We spent quite some time in doing market and customer research before setting up the development teams for software for this product program so it was not until fall 2011 we got some UXD people on board. At that time we were doing different alternative designs and some quick prototypes to get material to use in the deep dive interviews and market research we wanted to do with real mockup devices. That gave us the initial vision on the UX for the device and in the beginning of 2012 we got first SW teams set up.
For the UI framework and apps SW setup we decided to use Scrum. We coupled UXD tightly to the SW cycles and as often happens the initial sprints were done without UXD that was to be final. This was the whole point of doing things in Scrum: we start with something, see how it turns out and make informed decisions what if anything to change.
The team location setup was not ideal. The Development Teams were in Oulu and the UX designers were sitting in Espoo. To reduce risks related to Dev Teams and UXD not being co-located we got into practise to get the UXD team members visit us in Oulu and to do joint Sprint Plannings. After few Sprints in this fashion we converted to having the UXD team join in our planning session via teleconference. This proved to be somewhat suboptimal as the discussion was difficult to follow for those sitting in Espoo and they did not have much to contribute to the overall discussion about User Stories.
After few sprints the UXD had enough of design ready to be handed over to the Development Team. The team took the designs and tried to realize it with SW during a sprint. Quite often the SW turned out to be not as expected as the written specifications left quite much things open and then we had to rework the software in the next sprints. In effect, we were doing somewhat mini-waterfallish Sprints. It was pretty clear to me that this was due to lack of common understanding of what the details of the UXD was and how it was fitting together in the big picture.
Clearly this was not working as Scrum should. The things were not getting done. To help the situation I tried to pull the UXD team to work in concert with Dev Team in Oulu. This was unfortunately not possible. We thought of using Skype or some other personal video conferencing system. Those were not working for a reason or another. Then I decided to bluntly go against the rules and started booking our expensive but awesome tele presense system so that we could get all of UXD people and relevant Dev Team members to discuss open things and keep their common understanding better in sync. You may think that Skype would work just as well but there is not really any comparison. The telepresense system is a studio with negotiating table and four huge flat screen TV:s where the other side of the "table" is visible in natural size not to mention live-like sound quality. You just can't get this with a webcam and a headset. Using this system helped a lot. The designs could be discussed, things in progress could be demonstrated on live devices via the table camera and solutions to design challenges were quickly discovered. We tried to have at least 1 hour slot reserved for this each day. We set it up in a open space manner. Time was communicated to all and people could just walk in and see who was there and increase their understanding what was happening at the time in both locations.
In general the UXD and Dev teams were happy. UXD was particularly happy about the fact that they had very early live devices that had always working software available to review the software and communicate their views back to SW devs each day. Although some of the UXD was designed before the actual Sprint where it was to be realised this kind of daily opportunity was the key element for success. I dare to call this a success despite this could have been going even better if the working culture of the UXD team would have allowed for "unfinished" or "unpolished" designs to be floating around for Dev Team to pull in and do working software that was in the end the only measure of success.
We managed to deliver quite polished looking software for the consumer studies that were done with real devices. I am very proud to say that the software was also fully functional and well performing on the actual devices. It was so well functioning that the customers we showed the device to never suspected that it was just a "prototype" with minimal functionality. Not really a prototype but an increment of working software that was planned to be iterated upon several Sprints more. In the end that was not to happen. Stephen killed this product along with some others in June 2012 and that had career impact to me and many of my colleagues.
I will return to this topic "How to do UXD in Lean/Agile way" in the future.
Lean Enterprise Software and Systems 2012 in Tallinn
Just got back from the Lean Enterprise Software and Systems conference. This was my first time at LESS. I expected to meet old friends and make new ones and attend interesting sessions over the three days.
This year the venue was in Tallinn, Estonia. Euroopa Hotel had quite nice facilities for the conference and LESS organizer Agile Estonia had negotiated a good rate for the LESS attendees for accommodation. The hotel is located at the very busy port of Tallinn where several 2000+ capacity ferries shuttle between Tallinn and Helsinki. I managed to manoeuvre myself into the Viking XPRS boat in order to catch the Agile Finland team and discuss their expectations and get into the LESS2012 mood.
Day One
The conference started with Jurgen Appelo's talk about Why Melly Hates Her Job. Having seen that couple of weeks earlier at Topconf I stayed just long enough to notice what kind of difference the size of the room makes in the presentation. Jurgen was energized as usual but somehow his energy was not sufficient to fill up the room. At Topconf the room was probably too small for his session but it was full of energy and good flow. Same content, same delivery and totally different feeling.
First actual session I participated in was Agile Management Innovations – Change at Organizational Level session by Bernd Schiffer and Christian Dähn. They had nice collection of practises that the management can take up one by one and be on their merry road towards Lean Business. I quite like the idea and will definitely use that with clients, especially where adopting Scrum is seen as too big of a first step. This framework goes beyond Scrum with several practises so it can be used to expand the Lean ideas and ways of working after the Scrum teams are fully in orbit. Check out their site about more details on AMIs.
After the AMI session I jumped to the Beyond Budgeting track and went to see Peter Bunce on the Beyond Budgeting Principles. I had read something from the BeyongBudgetingRoundtable site but that did not fully prepare me to what was coming there. Beyond Budgeting is to businesses what Scrum is for software development. A holistic framework that can be used to transform how companies do business. I am still in the early stages in my journey for fully grasping BB but I am going to read some more and chat with people how to actually go about realising it. I spend rest of the day in the Beyond Budgeting track hearing real life stories from different organizations such as Statoil, Jernia (Norwegian hardware store chain) and Össur (maker of fine prosthetics). Jernia had made the transformation to use Beyond Budgeting but was now reverting back to command-control mode due to changes in the management team. Their situation sounded quite dire. I was actually shocked to learn that they did not have common information systems where they could see what was going on. No wonder the management felt that they needed to have better visibility through traditional management lines.
Day 1 was ended by Christopher Avery's fantastic keynote which I hereby rename to "LayBlame is not a village in France".
Day Two
Day two started with some hits and some misses. I missed Esko Kilpi's keynote in the morning and dived into Ken Power's talk about Value Stream Manager. What a novel concept and in my mind a perfect fit for manager(s) who are wondering what their role might be after the some level of Lean Transformation has taken place. Value Stream Manager looks at the value generation holistically from the idea generation to delivery of finished product or service to the customer and pre-empts getting potential or actual impediments removed so that value stream flow uninterrupted. I will look further into this as well.
Couple of misses after Ken's session but then came the highlight of my second day. Özlem Yüze was giving a great session about how Maersk had adopted Agile Systems Development in their organization. Fantastic story, well told and showed how big a job it is to keep things in orbit even if you initially get stuff rolling. I got (again) an inspiration to write something at the University again. I will keep you posted how that process takes flight (again).
Day two ended with Jason Little's session on how Lean Startup can be utilized also outside of the startup context. Good stuff there as well which I need to revisit after I finish the Lean Startup book.
Even though the LESS2012 setup was quite compact there were so many topics of interest that I have to read about some of the concepts some more before I can make any conclusions on them.
Day Three
Day three was just a half a day with couple of workshops in the tracks. Dawna Jones had ad-hoc session combined with Stephen Haas on the Cultural Hacks and Behavioural Change. That really made my day and was less sorry that I missed Stephen's session on Tuesday. This goes deep into what kind of things in the environment you can affect thus affecting people's behaviour and thus creating a organizational change.
All in all the LESS2012 was so far the best Agile Conference I have attended and I am looking forward to LESS2013 already. Meanwhile I shall read more and more importantly apply some of the learning with my clients in the near future.
This year the venue was in Tallinn, Estonia. Euroopa Hotel had quite nice facilities for the conference and LESS organizer Agile Estonia had negotiated a good rate for the LESS attendees for accommodation. The hotel is located at the very busy port of Tallinn where several 2000+ capacity ferries shuttle between Tallinn and Helsinki. I managed to manoeuvre myself into the Viking XPRS boat in order to catch the Agile Finland team and discuss their expectations and get into the LESS2012 mood.
Day One
The conference started with Jurgen Appelo's talk about Why Melly Hates Her Job. Having seen that couple of weeks earlier at Topconf I stayed just long enough to notice what kind of difference the size of the room makes in the presentation. Jurgen was energized as usual but somehow his energy was not sufficient to fill up the room. At Topconf the room was probably too small for his session but it was full of energy and good flow. Same content, same delivery and totally different feeling.
First actual session I participated in was Agile Management Innovations – Change at Organizational Level session by Bernd Schiffer and Christian Dähn. They had nice collection of practises that the management can take up one by one and be on their merry road towards Lean Business. I quite like the idea and will definitely use that with clients, especially where adopting Scrum is seen as too big of a first step. This framework goes beyond Scrum with several practises so it can be used to expand the Lean ideas and ways of working after the Scrum teams are fully in orbit. Check out their site about more details on AMIs.
After the AMI session I jumped to the Beyond Budgeting track and went to see Peter Bunce on the Beyond Budgeting Principles. I had read something from the BeyongBudgetingRoundtable site but that did not fully prepare me to what was coming there. Beyond Budgeting is to businesses what Scrum is for software development. A holistic framework that can be used to transform how companies do business. I am still in the early stages in my journey for fully grasping BB but I am going to read some more and chat with people how to actually go about realising it. I spend rest of the day in the Beyond Budgeting track hearing real life stories from different organizations such as Statoil, Jernia (Norwegian hardware store chain) and Össur (maker of fine prosthetics). Jernia had made the transformation to use Beyond Budgeting but was now reverting back to command-control mode due to changes in the management team. Their situation sounded quite dire. I was actually shocked to learn that they did not have common information systems where they could see what was going on. No wonder the management felt that they needed to have better visibility through traditional management lines.
Day 1 was ended by Christopher Avery's fantastic keynote which I hereby rename to "LayBlame is not a village in France".
Day Two
Day two started with some hits and some misses. I missed Esko Kilpi's keynote in the morning and dived into Ken Power's talk about Value Stream Manager. What a novel concept and in my mind a perfect fit for manager(s) who are wondering what their role might be after the some level of Lean Transformation has taken place. Value Stream Manager looks at the value generation holistically from the idea generation to delivery of finished product or service to the customer and pre-empts getting potential or actual impediments removed so that value stream flow uninterrupted. I will look further into this as well.
Couple of misses after Ken's session but then came the highlight of my second day. Özlem Yüze was giving a great session about how Maersk had adopted Agile Systems Development in their organization. Fantastic story, well told and showed how big a job it is to keep things in orbit even if you initially get stuff rolling. I got (again) an inspiration to write something at the University again. I will keep you posted how that process takes flight (again).
Day two ended with Jason Little's session on how Lean Startup can be utilized also outside of the startup context. Good stuff there as well which I need to revisit after I finish the Lean Startup book.
Even though the LESS2012 setup was quite compact there were so many topics of interest that I have to read about some of the concepts some more before I can make any conclusions on them.
Day Three
Day three was just a half a day with couple of workshops in the tracks. Dawna Jones had ad-hoc session combined with Stephen Haas on the Cultural Hacks and Behavioural Change. That really made my day and was less sorry that I missed Stephen's session on Tuesday. This goes deep into what kind of things in the environment you can affect thus affecting people's behaviour and thus creating a organizational change.
All in all the LESS2012 was so far the best Agile Conference I have attended and I am looking forward to LESS2013 already. Meanwhile I shall read more and more importantly apply some of the learning with my clients in the near future.
keskiviikko 27. tammikuuta 2010
ZarroBugs
Zarrobugs blog started. Or Zero Bugs. This refers to bug free software which naturally does not exist in the mainstream software world. More relevant stuff later.
Tilaa:
Blogitekstit (Atom)