Bookmark and Share
RSS

Recent Posts

Recapping Blogs on Areas of Innovation, Teams and Development Methods/Architectural Styles

January 22, 2018

This is the second of two recollections looking back at posts from IT Trendz published in 2017. In this post, I explore three more of the 12 themes and variations that I explored and discussed last year. My focus in this post is areas of innovation (the chicken or the egg question), team structures (like you, I have experienced and observed a variety of organizational constructs) and ways to develop applications (including a discussion of architectural styles). 
 
Areas of Innovation in IT: The Drive for New Technology  
I wrote five posts starting in late July on the roots of new technology. One of the main ideas in this series was to explore this question: Is need driving innovation or is innovation driving demand? After investigating the human side of the question, I dove into specific technology areas, like B2B innovations where collaboration involving sales and information sharing will help the B2B market reach $6.7 trillion by 2020, dwarfing B2C. I also discussed cloud, APIs and mobility. All three areas of innovation are as important and substantial as B2B. 
 
How Teams Work Together 
This series of four posts gave me the opportunity to reflect on different team organizations that I have been part of or have observed in operation. 
 
Hierarchy Aligns With Operations 
This post described a hierarchical IT organization with members having roles that align directly with the job of adding and fixing applications for a company with thousands of employees who move millions of dollars worth of goods around the country daily. Hierarchical structures dominated development organizations four decades ago. This was my experience as I changed jobs every couple of years to gain new experiences as an application developer and then as a system programmer. 
 
Federation Unified by Process 
This post described an organization that created products and offerings with members who work simultaneously on multiple projects. A well-defined process, not very different from a traditional system’s development life cycle, guided this federated team. One of the big challenges for team members was getting detailed work done—like product costs cases or contract development—while meeting the needs of project managers and executives who want to be briefed on status and project developments. Some days, we had six hours of planned conference calls.
 
Group in a Box United by Schedule 
This post described a team that created software by having members work on multiple line items on the same projects within a fixed time period. It can be described as a group in a time box unified by schedule. This team felt significant pressure to close line items, while the development process itself resulted in the discovery of new work from defects and the identification of missing (but needed) supporting functionality. This mix of existing and new work made it challenging for developers to report progress of line items (or even status).  
 
What Makes Them Effective? 
This post examined the characteristics of teams that make them effective, regardless of the way they are organized to carry out their work. Five findings included:
 
  1. Team members function best when they are treated with trust and respect
  2. Strong leadership is also an important factor, as it’s needed to help propel teams forward
  3. Another factor is team and individual reliability. Members and leaders of teams need to do what they say they will do, otherwise the team could falter.  
  4. Teams work well when they have a balance of introverts and extroverts as this mix of personalities and work style provides equilibrium
  5. Proactive communication is important. Project leaders need to establish communication channels that work effectively.  
 
How Applications are Developed and What Styles are Used
Starting in May, I wrote about development methods (i.e., waterfall, agile, etc.) and architectural styles (i.e., pseudo-conversational, microservices, etc.) and how they are paired to work together. 
 
Methods aren’t the same as styles and some pairings work better together than others. This post starts with a bit of history. 
 
The focus of this post was on development methods and architectural styles that are becoming more prevalent. As I remarked in the first post, methods aren’t the same as styles and some pairings work better together than others. This post examined different factors that impact choices and pairings.
 
In this post, I discussed the natural alignment between certain methods and styles. For example, an alignment can be found between the waterfall method and monolithic applications, as well as between agile methods and microservices. I explored these examples of natural alignment in this final post of the series.
 
What’s Next?
Next week, I’ll start a new series on a business strategy topic. The topic is consolidation. It is time to take a fresh look at the idea of combining workloads to simplify and save. 
 

Posted January 22, 2018 | Permalink

comments powered by Disqus