Fun Friday Miscellaneous Tool – [We review Agile tools. Have you seen our Agile tools list?]
Listhings.com is a fun site similar to that of an Evernote but with virtual stickynotes. I’m wondering if this would be valuable for a small team to plan work with… virtually. Though I’m still a huge fan of physical wallboards being the best.
Try it out for free. After October 10, 2011 you’ll have to sign up to mess around on it.
[Guest Post: Craig Strong, MBCS CSM has been involved with software production for over 12 years and is currently contracting as a ScrumMaster for Sky. Having been a developer Craig has experienced first hand the effects and problems when being managed by various project management techniques and frameworks. On a daily basis Craig is responsible for managing,coaching and improving cross functional teams using Agile. Follow him on Twitter @craigstrong and blogs at www.c6s.co.uk]
With Agile becoming so popular a lot of companies are jumping in to adopt it. With any new great idea, often people hear the benefits and want it without fully investigating the requirements to achieve the desired goal.
The Way It Used to Be
Those moving from a traditional project structure are used to assigning project managers who ultimately are responsible for a products success. Such roles take on a long list of responsibilities which are filtered to them via stakeholders, customers, product managers via individuals or committees and so on. The project manager then proceeds to create a long list of features to satisfy their demands, then gets the stakeholders and/or customers to sign their name in blood in absolution for everything they want and specifically ask for. Prior to this of course, the project manager may have estimated the length of the project and broke it down into a lovely gantt chart which may as well be etched in stone.
In the above scenario, where does the power actually sit? The production teams who develop the product are told exactly what to do and how long it should take them, the stakeholders have stated and signed off their demands and then may sit back, also the customer has predicted the future and signed this in absolution until it’s completion, and the project manager administers the flow of the work from beginning to end and is answerable to the deadline. So what happens if change is required and who identifies it? With often little involvement by the customers and stakeholders during the project, is it easy to make change?
Change is the one major factor that needs to be recognised early and implemented as soon as possible. It’s change that builds opportunities or destroys competition. Although this may sound obvious enough, why then are so many traditional structures built around rigid organisation or project structures?
A natural and gifted leader, he is more than a coach (and world famous conductor). He is a man who is helping people unlock the ‘possibility‘ inside of themselves.
Please, watch the above video of how Ben Zander transforms before your very eyes a musical piece many of us have heard before. He brings it alive through a 15 year old boy Nicolai, who (to my ignorant ears) did quite well on his first pass of the piece. But… as you see how Ben coaches the 15 year old, you will see a transformation take place… the music comes alive.
This is what it means to be a coach, a change agent in enterprises, teams, and individuals. A true Agile coach is one who sees the potential, makes visible the possible, and guides those to achieve them.
I promise, watching this 30 minute clip will be the best lunch break you’ve had in a good while.
According to a new study of Cuban software developers finds that more developers are ESTJ than anything else… which means… developers are social, or more social than the stereotype!
The aim of this study was to establish the personality profile of Cuban software engineers according to the Myers-Briggs Type Indicator (MBTI). Analysis of the study shows that the most prominent personality type is a combination of extroversion, sensing, thinking and judging.
Human factors in software engineering have different dimensions. Studies have been conducted from different perspectives. These perspectives could be the study of human factors in different phases of the software life cycle, or the effect of teamwork on software development, or how a personality profile can suit a particular task or about some other miscellaneous issues.
Although 20 years ago software developers (systems analysts and programmers) had the lowest need for social interaction on the job, at present, human resource professionals responsible for hiring software engineers state that in addition to knowledge in applied computing and business, it is also very important that software professionals have the capacity to learn, ability to work in teams, oral and written communications skills and an orientation toward health and well-being. In short, adaptability, communication and stress management are seen as key skills for software engineers nowadays. Yet, such skills are not developed through logic and algebraic reasoning alone; they involve soft areas of intuition, feelings and senses.
In this study, the most prominent personality type was a combination of extroversion, sensing, thinking and judging. For example, ESTJs are known as being practical and realistic individuals; they lead people and make things happen and, thus, are more likely to rise to management positions. At present, planning, management and analysis are more dominant tasks than programming, and client-developer interaction is also required. Even selected software development methodologies tend to be agile, which means that programmers must be communicative and receptive. It is, therefore, possible that future studies will show extroverts more widely distributed than introverts in the software industry.
“The Executives Guide to Information Technology is an excellent resource that is a must have for IT managers and top executives that want to get the most out of their IT investments. Every IT manager and executive should read this book to understand how to effectively manage information technology for business value. Likewise, non-IT managers and executives will learn a great deal about the inner-workings of IT and how to work with their IT brethren in the most effective way for the greatest benefits to their company. (CFOs specifically will find this book incredibly illuminating and useful).
The book is extremely well organized and presents a well-balanced mixture of academic analysis and tested practices. The sheer knowledge and hard earned personal experiences of the authors comes through in every chapter. The descriptions of the challenges facing IT will resonate clearly with anyone who has ever held an executive position within an enterprise IT team. The solutions presented are equally clear and easy to follow. Overall, the book is simply packed with techniques for recognizing challenges, accurately assessing the current state of any component of IT, comparing that state to a target benchmark and developing actionable improvement plans. Finally, the CD-ROM included with the book contains all the spreadsheets, documents and checklist tools needed to put Baschab and Piot’s sage advice to immediate use.
In addition to being a highly informative volume, this is ultimately, as the title implies, a guidebook loaded with recipes for IT investment optimization success. After reading it, I suggest placing it on or near your desk where I am sure you will refer to it again and again. Also, I think that buying a copy of this book for each of their key IT managers would be one of the wisest investments a budget-squeezed CIO could make.”
How to enter:
Comment on this post
Tweet this post
Simple. Jump on it! Contest entry closes (for this month) on Sept 30, 11:59PM.
This year’s US Agile Coach Camp will kick-off this weekend following the outstanding camps held in Norway, Germany, Canada, and elsewhere. The Camp organizers couldn’t be happier about continuing the fine tradition from prior Camps both inside and outside the US. Agile Coach Camp was started by Deborah Hartmann-Preuss and Naresh Jain and held in Ann Arbor, Michigan. Since then additional Camps have been added around the world.
The primary goal for these Camps is to bring Agile Coaches together to share experiences and develop new ideas that will assist each other as they help organizations in adopting Agile. The Camps use an Open Space format such that everyone is a participant; there aren’t any ‘speakers’. Each camp is organized by a team of coaches that come together out of inspiration to bring others together for connecting and sharing information. many coaches work alone and rarely get to have a forum to better their coaching skills and develop new directions forward for themselves. Agile Coach Camps give coaches that opportunity.
The Camp this year will be in Columbus, Ohio 24-25 September with a Games Day prior on 23 September. This year’s theme is S’mores, a play on words for that great camping treat… Getting S’more Learning,making S’more Connections, and having S’more fun is what it is all about. The US Camp’s hope is that it will inspire people to go back to their local Agile communities and stand-up their own small self-organizing, self-help groups such as the Agile Influencers of DC (AID). Agile Coach Camp has a wonderful set of sponsors; our title sponsor GrowthPlus has worked hard to make sure this is the event to remember. We are also happy to have Mike Sutton of Wizewerx to facilitate our event; he’s traveling quite that distance to help make our event truly special.
The US Agile Coach Camp Games Day and Camp itself had sold out by the beginning of August and tickets were increased to accommodate more people.
This may be a bit revealing… but whenever I think of the word “art” I mentally go through a quick mind map:
Art -> Colors -> Clown -> Stephen King -> Pennywise -> IT -> Scary -> Art = Scary
So, I thought it would be appropriate to create the collage you see above.
Art Exhibits, Art Authorities, Art Institutions – Go Agile!
As for this article, it seems that art authorities are taking notice of Agile… or at least using some of it’s nomenclature. The Digital R&D Fund for Arts and Culture held a panel discussion on how things were going, some interesting and notable quotes:
Digital and arts collaborations, you have different cultures between developers and marketing…
Getting all people together at the start, to see the whole product. Everyone gets to have their own view of the product.
We became iterative… each step of the way people worked with us to break down barriers.
Lots of face-to-face meetings and collaborative tools to share ideas.
It’s Agile, flexible, everything become iterative, and you feedback constantly, user experience, content, technology.
Have to keep the feedback loop going.
We have to have a collaborative model.
We have a vision of openness… visions of Shakespeare… (not sure what that is).
I’ll be honest, the video below is quite boring, but for a guy like me who is crazy about Agile-stuff… well, I just get a kick out of it.
I’m sure you’ve heard of Thomas Edison. That guy who is often quoted:
“Genius is 1 percent inspiration, 99 percent perspiration.”
Edison is the third most prolific inventor in history, holding 1,093 US patents. He is credited with numerous inventions that contributed to mass communication and, in particular, telecommunications.
First Agile shop in 1876
Edison established an industrial research laboratory in New Jersey (Menlo Park) as early as 1876. That puts the elements we now call “Agile” in practical commercial use in the 19th century. What’s more, one could easily make the case that the industrial research laboratory is modeled on the practices of academic research and scientific method, which dates to the 17th century.
Menlo Park became the first institution set up with the specific purpose of producing constant technological innovation and improvement. Edison was legally attributed with most of the inventions produced there, though many employees carried out research and development under his direction. His staff was generally told to carry out his directions in conducting research, and he drove them hard to produce results. – Wikipedia
Edison was a master at the art of never-giving-up. He continually improved upon older technologies, looked at things differently, and empirically approached improvement. Sounds like he was the master Agilist of the time.
We’re all pro-Agile and pro-Lean Startup here, right? In most all cases, there is a significant value difference when you build products in a traditional method versus an Agile method. Agile just #wins, right?
Well not so fast. Coach Wei, the founder and CEO of Yottaa (pronounced like Yoda-Jedi-Master), says no to Agile and lean startups. His 2 year old company from Cambridge, MA makes software tools to help business websites run faster, monitor their performance, and generate sales more efficiently, or Web Performance Optimization.
Wei recently talked with Greg Huang from xConomy in depth about what he’s doing with Yottaa. You might call it the “anti-lean startup.” In some ways, it is the opposite of the lean startup model, started by Eric Ries, which involves having a small team, creating software prototypes quickly, and using customer feedback to rapidly iterate code.
As Wei explains, that approach works well for some social media and Web startups, but not all. In particular, he says, if you’re trying to build a company that will be able to grow from, say, $1-5 million in revenue to $50 million, you could run into difficulties with the lean startup model. If you start small and local, ramping up to hire a team of 100 people in Boston or San Francisco will be almost impossible because of the current talent crunch and skyrocketing cost of good developers. “There’s a huge scalability gap,” Wei says.
So he’s trying something different at Yottaa—and he’d probably be the first to acknowledge that it might not necessarily work. The idea, he says, is to be “global from day one and have scalability built in.”
Translation: hire most of the team in Beijing and the rest in the Boston area, from the start. “We try to integrate the best of here, and the best of China, to build a company,”
Yottaa is positioning itself to grow quickly by tapping into Beijing’s developer talent pool (which Wei says is very deep and fast-moving) and making that a fundamental part of the company’s culture.
But having the team split across such a huge distance is very challenging, especially for a startup. In fact, geography is a big reason why techniques like agile software development don’t work for Yottaa—fast iterations and code releases (on a daily basis, say) usually require developers to be in the same room.
Currently, he says code development has “converged to a semi-agile, semi-waterfall [traditional]” model and regular visits to Beijing and daily meetings and e-mails are the norm at Yottaa.
Yup, doesn’t sound too Agile to me. I’m very interested in how this will fair. I’ll keep my eyes on this as it progresses!
I’m on cloud9 right now. This past Product Camp Atlanta was simply the best one I’ve ever participated in. The sessions were absolutely fantastic… plus… I won BEST SESSION and the random lottery for an iPad 2!!!
Today is my day. Love it. Thanks to everyone out there who voted!!!
[Guest Post: Paul Boos serves as the software maintenance lead for the Environmental Protection Agency’s Office of Pesticide Programs (OPP). His team currently uses Kanban and Scrum to maintain the OPP legacy code base. Prior to that he implemented Scrum as the Branch Chief for the National Development Branch within USDA/Rural Development. Follow him on twitter: @paul_boos]
Creating a Culture for Government Innovation following the Feng Shui
In my last post, I discussed characteristics of the innovation Personae, but how do we harness the power of our people to actually create innovation. What does it take to have team be successful in an innovation? All teams operate with a set of values, usually implicitly. In this post, I am going to discuss the 4 primary values that a innovative team will exhibit. These values are what allow a team to be creative in constructing and implementing an innovation.
The first value is one of recognizing that Team Interactions between People is how information gets shared and product or service innovation gets constructed. Without interactions, nothing will get produced. The higher the bandwidth these interactions take place, the faster construction can take place. If one relies on email and written documents, a lot of useful information gets lost. For starters, the amount and type of questions that get asked is curtailed and questions provide clarity on information. Without clarity, what gets constructed and how it gets constructed may be not be a best fit for the innovation needed. This is not to say that documents won’t get created, but they should get created or shared alongside a set of interactions, preferably face-to-face.
Focus on Working Product
The second value is to focus on a working product (or service); it is not until there is a working product or service that interactions can become more meaningful. Will the product or service meet the need? It’s not exactly known until on is in place and a gap analysis can be done. Additionally by focusing on getting a working product or service that is providing value to an end customer, the providers can begin having a feeling of accomplishment, even if it still needs changes to meet the needs entirely. This helps maintain the passion of the individuals in the team and gives them something to focus their learning on.
I’ve been using Kanban at the enterprise level as a way to engage executive leadership visually to see an entire PMO project portfolio (and I’m sharing a story about this at AgileDC in October for my Scaling Product Ownership talk). What has come up through these assessment sessions has been very interesting to say the least. Now, applying Kanban to bug remediation and defect resolution processes is somewhat straightforward. What if we look at how software development really works?
Kanban, a system based off of manufacturing inputs and outputs, doesn’t say much about re-queuing things. What I mean is, we look at Kanban, work in progress limits, etc etc, and see the card go through the line. Then it’s done.
In the software development world we have reusable processes, we have repeatable steps, and we have recycled stories. Kanban doesn’t really address the whole re-queuing thing.
So the thought in my mind is: “So let’s talk about versioning.”
“You can always create a new version of the repeatable card, story, or step.”
But this doesn’t seem to sit well with me. I’m not so sure I’m convinced.
So what happens when you need to send that repeatable story through the line… several times, or even greater, what about an entire multi-story process?
James Martin was European IT COO at Lehman Brothers when the investment banking giant collapsed in 2008. Now in August 2011, James has created a company called Firmrater to provide online performance benchmarking for UK firms. As they began development, he wrote a very compelling article on how they build the company and system, based on Scrum software development.
Produce fully detailed functional specifications before starting development – Interesting…
Provide a “low distraction, high freedom” working culture for the whole team
Some more quotes from James’ paper:
“If your own money is tied up in a development project you clearly need to do everything you can to make sure the time and cost stays under control and you get the product you need to launch your business.”
Nobody has a crystal ball so producing a traditional project schedule in advance is fraught with risk. Why not abandon the detailed schedule altogether? You can’t slip interim milestones if you don’t have any and you can’t add padding into them either.
To give ourselves the best chance of producing the application in the shortest possible time and at the lowest cost, experience dictated that we produce detailed specifications describing all functions along with a mock-up of each web page.
Overall we spent about 5 months (48% of total project duration) producing the specifications, which was time very well spent. To accelerate the start of development, placeholders were left for text content as this could be dropped into the application later. This enabled us to work on the website content in parallel with development of the application and cut the launch timescale by several weeks.
[Graphic made with Omnigraffle for Mac, which is 10x better than Visio on the PC]
Typically we find that when changes need to be made in any process, the process owner must approve a change before it is made. Then we find that the process owner has to approve the change before it is implemented. This generally takes a long period of time… or rather, much longer than is necessary.
The usual flow is:
Someone recognizes the need for change (change agent) and requests to make the change to the process owner
The process owner gives approval
The change agent makes the change.
The change agent preps the final change for approval
The process owner gives final approval for the change implementation
The change agent implements the change with other people
What needs to happen is that if you train a group of people to do the work, so that anyone can make the change, then change can happen quickly. If you encourage change agents to communicate the recognized need for change transparently, maybe through a collaborative system, then any one of the group can pick up the change and make the change.
Agile can work for fundraising. It obviously works for Wikimedia, who has been using Agile to help their fundraising effort.
This year, the fundraiser engineering team of Wikimedia is following agile methodology that came out of an ‘inception’ process facilitated by ThoughtWorks.
During the process, they defined and prioritized the high-level requirements for this year’s engineering efforts, identified pain points in our development process, and strategized solutions to enable the team to quickly respond to the constantly changing needs of the fundraiser at a sustainable pace.
Consider the following ideas when managing fundraising efforts:
Creating a fully prioritized list of fundraising activities or features needed to do.